Skip to main content
Visit the following sections to see how to configure the Database for Production: Please consult the data storage configuration guide for further information relating to how to configure Tyk’s data storage across different database engines.

​
Redis

​
How Tyk Uses Redis

Redis is central to Tyk’s operation. Its role differs depending on whether it is serving a Control Plane or a Data Plane. Control Plane Redis is shared between Tyk Dashboard and the Management Gateway. It stores: Data Plane Redis (used in distributed deployments) is local to each Data Plane cluster. Data Plane Gateways handle API traffic and use their local Redis for:
  • Rate limiting counters.
  • API response caching.
  • Webhook deduplication, preventing duplicate events from firing within the configured timeout.
  • Traffic logs buffered before Tyk Pump processes them.
  • A local copy of API client Sessions and certificates, synced from the Control Plane.
  • API definition and policy backups, providing resilience when the Control Plane is unavailable.
In deployments without Tyk MDCB, there is no Control Plane / Data Plane split. A single Redis instance covers all of the above, shared between Tyk Gateway, Tyk Dashboard and Tyk Pump.

​
Protecting Redis Data

Tyk’s Redis usage differs between the Control Plane and Data Plane, and the consequences of losing each are different. Control Plane Redis stores API keys, session data, OAuth tokens, and certificates. This is the source of truth for your deployment and cannot be recovered from any other Tyk component. Deploy it with persistence enabled and a high-availability topology such as Redis Sentinel or Redis Cluster. If you are using Amazon ElastiCache, also configure read replicas and regular snapshots. Data Plane Redis stores rate limiting counters, cached responses, and analytics buffers, plus a local copy of keys, sessions, and API definitions synced from the Control Plane. If Data Plane Redis is lost, the impact is temporary: keys and sessions re-sync from the Control Plane on reconnection, and API definition backups rebuild on the next hot reload. High availability is still recommended to avoid disruption during a node failure, but Data Plane Redis is recoverable in a way that Control Plane Redis is not. For configuration details, see Configure Redis.

​
Redis Sizing Guidelines

Redis memory requirements depend on what the instance is serving. Control Plane Redis memory is driven primarily by the number and size of API keys, API definitions, and security policies stored. Key size is typically small (around 1KB), but large key counts or large API definition payloads can add up quickly. Data Plane Redis memory is driven by traffic volume and feature usage. The main contributors are:
  • Traffic log buffering: traffic logs accumulate in Redis between purge intervals. Basic analytics records are typically around 2KB; detailed logging can reach 52KB per request. Logs are processed by Tyk Pump or, in distributed deployments, by Tyk MDCB.
  • Response caching: cached API responses are held in Redis for the duration of their TTL. Memory usage depends on cache hit rate, TTL, and average payload size.
  • API definitions and policies: a local copy is stored in Data Plane Redis for resilience.

​
Redis RAM Calculator

Use this calculator to estimate the RAM requirements for your Redis instance when using Tyk. This tool helps you plan your infrastructure by calculating memory needs based on your expected API traffic, caching requirements, and analytics storage. The calculator considers factors like requests per second, cache hit rates, number of API keys, and analytics settings. Results show the total RAM per host accounting for your specified utilization threshold.

​
Managing Redis Memory

​
Capping Analytics

Tyk Gateways can generate a large volume of analytics data. Be sure to read about capping your Dashboard analytics.

​
Compressing API Definitions and Policies

In distributed deployments, Data Plane Gateways store API definition and policy backups in Redis to ensure resilience when the Control Plane is unavailable. For deployments with many or large API definitions, this can consume significant Redis memory. You can reduce the size of these backups using optional Zstandard compression, which typically achieves around 75% reduction, though results vary depending on the size and complexity of your API definitions and policies. Set the following fields in your Data Plane Gateway configuration: 
"storage": {
  "compress_api_definitions": true,
  "compress_policies": true
}
Tyk Gateway reads uncompressed data already in Redis seamlessly. On the next hot reload, definitions and policies are compressed before being stored. To mitigate the risk of decompression bombs, the maximum combined uncompressed size is limited to the value of storage.max_decompressed_size.

​
Separate Analytics Storage

By default, Tyk Gateway writes traffic logs to the same Redis instance used for rate limiting, session data, and other gateway operations. Under high traffic, this can place significant pressure on your primary Redis. You can offload traffic log buffering to a dedicated Redis instance by enabling a separate analytics store: 
"enable_separate_analytics_store": true,
"analytics_storage": {
  "host": "analytics-redis-server",
  "port": 6379
}
The analytics_storage block accepts the same fields as the main storage block. See Configure Redis for the full field reference.

​
Separate Cache Storage

API response caching can consume significant Redis memory, particularly for large payloads or high cache hit rates. You can isolate cache storage in a dedicated Redis instance, keeping it separate from session and rate limiting data: 
"enable_separate_cache_store": true,
"cache_storage": {
  "host": "cache-redis-server",
  "port": 6379
}
The cache_storage block accepts the same fields as the main storage block. See Configure Redis for the full field reference.

​
MongoDB

​
Supported Versions

MongoDB is our default storage option. We support the following versions:
  • MongoDB 5.0.x, 6.0.x, 7.0.x (with mongo-go driver).
Note: mongo-go driver has been available since Tyk 5.0.2 and is the default from Tyk 5.3.0.

MongoDB 3.x to 4.4.xPrior to Tyk 5.0.2, Tyk used the mgo driver which supported MongoDB 3.x to 4.4.x, but we no longer test MongoDB versions prior to 5.0 since they are EOL.
We can not guarantee full compatibility with these versions of MongoDB for Tyk and recommend upgrading to a supported MongoDB version. In particular, when using Tyk OAS APIs with Tyk 5.3.0 onwards, the minimum supported version of MongoDB is 5.0.
You can also use the following as a drop-in replacement for MongoDB:

​
Choose a MongoDB driver

From Tyk 5.0.2, we added an option to use the official MongoDB Go driver to connect to MongoDB. We recommend using the mongo-go driver if you are using MongoDB 4.4.x+. For MongoDB versions prior to 4.4, please use the mgo driver. With the mongo-go driver, we support the latest versions of MongoDB (5.0.x, v6.0.x, and v7.0.x) and also features such as the “+srv” connection string and SCRAM-SHA-256. For more details, visit the MongoDB doc: You can configure which driver to use with the MongoDB driver option: For recommended deployment topology, see Planning for Production. Special notes for DocumentDB
If you are using DocumentDB, capped collections are not supported. See here for more details.
Special notes for MongoDB Atlas To integrate with MongoDB Atlas, make sure the IP firewall connections are whitelisted on the Atlas side, and then use the following Tyk Dashboard configurations to connect: 
- TYK_DB_MONGOURL=mongodb://admin:password@tykdb-shard-00-00.h42pp.mongodb.net:27017,tykdb-shard-00-01.h42pp.mongodb.net:27017,tykdb-shard-00-02.h42pp.mongodb.net:27017/tyk_analytics?authSource=admin - TYK_DB_ENABLECLUSTER=false - TYK_DB_MONGOUSESSL=true
More information on these configuration variables here.

​
MongoDB Sizing Guidelines

The aggregate record size depends on the number of APIs and Keys you have. Each counter size is ~50b, and every aggregated value has its own counter. So an hourly aggregate record is computed like this: 50 * active_apis + 50 * api_versions + 50 * active_api_keys + 50 * oauth_keys, etc. The average aggregate record size (created hourly) on our cloud is about ~ 40KB (a single record includes all the aggregate stats mentioned above). So for 1 million requests per day, it will generate 1KB * 1M request stats (1GB) + 24 * 40KB aggregate stats (~1MB). Per month: 30GB request logs + 30MB aggregate logs MongoDB Working Data Working data in terms of MongoDB is the data you query most often. The graphs displayed on the Tyk Dashboard, except for the Log browser, use aggregated data. So if you rely only on this kind of analytic data, you will not experience issues with working data and memory issues. It is literally hundreds of MBs. Even if you use the Log browser, its usage access is usually quite random, and it is unlikely that you check requests for every request. So it can’t be called working data. And it is ok to store it on disk and allow MongoDB to do the disk lookups to fetch the data. Note, that in order to do fast queries, even from the disk, MongoDB uses indexes. MongoDB recommends that indexes should fit into memory, and be considered working data, but only the part of the index which is commonly used. For example the last month of data. For an aggregate collection, the average index size is 6% of the overall collection. For requests stats, it is around 30%. MongoDB Sizing Example If you serve 1 million requests per day, and require fast access to the last seven days of request logs (usually way less, and the performance of the log viewer is not a concern), with 3 months of aggregated logs, the memory requirements for MongoDB can be as follows: Request_logs_index ( 30% * (1GB * 7) ) + aggregated(3month * 30MB) ~= 2.1GB + 90MB = ~ 2.2GB In addition to storing working data in memory, MongoDB also requires space for some internal data structures. In general, multiplying the resulting number by 2x should be enough. In the above example, your MongoDB server should have around 4.4GB of available memory. Audit Log storage From Tyk Dashboard v5.7+,the audit log can be configured to be stored in the database. If you choose to store the audit logs in the database, you need to account for additional storage for audit logs in the database setup. The size of this table will depend on the number of operations recorded, with each record averaging 1350 to 1450 bytes. Audit Log Considerations
  • Data Generation: The total size of the audit log table will depend on the number of API operations, administrative actions, and system events that are being logged.
  • Daily Estimate: For example, logging 100,000 operations per day results in 135MB to 145MB of additional data daily.
  • Storage Growth: Over time, this can significantly impact your storage requirements, especially in high-traffic environments or systems with comprehensive logging enabled.
Recommendations for Housekeeping the Audit Log Table
  1. Implement Data Retention Policies: Define a clear retention period based on business and regulatory requirements, such as 30, 90, or 180 days. Remove older logs that exceed the retention policy to prevent excessive storage growth.
  2. Archive Older Logs: For long-term storage or compliance purposes, move older logs to external systems such as a data lake, object storage (e.g., S3), or a data warehouse.
  3. Monitor Growth Trends: Use monitoring tools to track the size and growth rate of the audit log table. Adjust retention policies or resources proactively based on observed trends.
  4. Plan for Resource Scaling: Audit log storage can significantly impact overall database size, especially in high-traffic environments. Plan for storage and resource scaling based on daily log growth estimates.
Example Calculation:
  • Daily Logs: 100,000 operations/day
  • Average Record Size: 1400 bytes
  • Storage Growth: 100,000 × 1400 bytes/day = 140MB/day
For 90 days: 140MB × 90 = ~12.6GB MongoDB Database Storage Calculator You can calculate your MongoDB storage requirements by entering your known values in the middle section of the calculator settings below:

​
Database Storage Calculator

Use this calculator to estimate the storage requirements for your database when using Tyk. This tool helps you plan your database infrastructure by calculating storage needs based on your API traffic, analytics retention, and configuration data. The calculator considers factors like requests per second, analytics time-to-live, and the number of APIs and policies you manage. Results show the total storage requirement accounting for your specified utilization threshold.

​
PostgreSQL

How you configure your PostgreSQL installation depends on whether you are installing Tyk from fresh using PostgreSQL, or are migrating from an existing MongoDB instance. Supported Versions From Tyk 4.0, you can use PostgreSQL as your datastore. We support the following versions: You can also use the following as a drop in replacement for PostgreSQL: For POC, you can also use the following as replacement:
  • SQLite 3.x

​
Migrating from an existing MongoDB instance

For v4.0 we have provided a migration command that will help you migrate all data from the main storage layer (APIs, Policies, Users, UserGroups, Webhooks, Certificates, Portal Settings, Portal Catalogs, Portal Pages, Portal CSS, etc.).
The migration tool will not migrate any Logs, Analytics, or Uptime analytics data.
  1. Make sure your new SQL platform and the existing MongoDB instance are both running
  2. Configure the main part of the storage section of your tyk-analytics.conf:
{
...
  "storage": {
    ...
    "main": {
      "type": "postgres",
      "connection_string": "user=root password=admin database=tyk-demo-db host=tyk-db port=5432"
    }
  }
}
  1. Run the following command:
./tyk-analytics migrate-sql
You will see an output listing the transfer of each database table. For example: Migrating 'tyk_apis' collection. Records found: 7.
  1. You can now remove your mongo_url (or TYK_DB_MONGOURL environment variable) from your tyk-analytics.conf
  2. Restart your Tyk Dashboard

​
PostgreSQL Sizing Guidelines

The aggregate record size depends on the number of APIs and Keys you have. Each counter size is ~50b, and every aggregated value has its own counter. So an hourly aggregate record is computed like this: 50 * active_apis + 50 * api_versions + 50 * active_api_keys + 50 * oauth_keys, etc. The average aggregate record size (created hourly) on our cloud is about ~ 40KB (a single record includes all the aggregate stats mentioned above). So for 1 million requests per day, it will generate 1KB * 1M request stats (1GB) + 24 * 40KB aggregate stats (~1MB). Per month: 30GB request logs + 30MB aggregate logs PostgreSQL Database Storage Calculator You can calculate your PostgreSQL storage requirements by entering your known values in the middle section of the calculator settings below:

​
Database Storage Calculator

Use this calculator to estimate the storage requirements for your database when using Tyk. This tool helps you plan your database infrastructure by calculating storage needs based on your API traffic, analytics retention, and configuration data. The calculator considers factors like requests per second, analytics time-to-live, and the number of APIs and policies you manage. Results show the total storage requirement accounting for your specified utilization threshold.