Skip to main content
Tyk components rely on two categories of storage, each with different durability and performance characteristics:
  • In-memory database, typically Redis, holds short-lived, frequently-accessed data - Sessions, rate limiting counters, caches - that needs to be fast and consistent across nodes. Some of it is recoverable if lost; some (Control Plane Sessions, in particular) is not.
  • Persistent database holds the durable source of truth - API definitions, policies, users, analytics - that cannot be regenerated if lost.
Getting either wrong in production has real consequences: an under-sized or unprotected in-memory instance can drop Sessions and disrupt live traffic, and a misconfigured persistent database can mean losing your API estate outright. The sections below cover how to size, protect, and tune each. Both split along the same boundary - what’s shared between the components that coordinate together, and what’s kept separate: See In-Memory Database for how Redis is used, protected, and sized across the Control Plane and Data Plane. See Core Platform Persistent Database for how the Core Platform’s persistent database is used, tuned, and sized. Tyk Developer Portal’s own database is covered in Configure SQL Storage. Connection configuration for each engine, and its compatible alternatives (such as Valkey for the in-memory database, or MongoDB-compatible services for the persistent database), is covered in Configure Redis, Configure MongoDB, and Configure SQL Storage.