Grafana remote cache with Redis or Memcached

When a Grafana remote cache with Redis or Memcached is worth the extra component

A remote cache is worth adding when a shared Grafana runs on two or more instances behind a load balancer and the database is already under load. A single instance serving a small group of users does not need one, and the supplied Grafana sizing baseline for small deployments (under 25 concurrent users on 2 cores and 2 to 4 GB of RAM) is the point where most teams should first check whether the database, not the web tier, is the bottleneck. The remote cache is an addition to a MySQL or PostgreSQL database, never a replacement for it: the database remains the system of record for configuration, users, dashboards and alert state, and the supported production and high availability setup still depends on MySQL 8.0 or later or PostgreSQL 12 or later.

The cache exists to take repeated, short-lived reads off the database so that many instances can serve dashboards without each one querying the same tables. Grafana's high availability model is two or more active-active servers sharing one database, with database-backed auth tokens so that users can reach any node. Before adding Redis or Memcached, confirm in the Grafana configuration documentation which cache backends the version you run supports, the exact settings for the remote cache connection and the minimum supported versions of each backend. Also check how your Grafana version handles any data it cannot cache, since those reads will keep hitting the database regardless of the cache.

Decide with evidence rather than habit. Measure database connection wait, query latency and CPU on the database host during peak dashboard use, then compare those numbers after adding instances. If the load comes mainly from alert rule evaluation or from slow data source queries, a cache will not relieve it, and the work belongs in alerting design or the data sources themselves. Plan for the extra component to be operated like any other stateful service: it needs its own monitoring, a failover design if Redis is used, and a restore path, because a cache outage should degrade performance without taking down the shared instance.

Choosing the cache backend by deployment shape

A single Grafana instance on SQLite or a small database keeps its configuration, sessions and cached data close to the process, which keeps the setup simple. The Grafana installation docs say SQLite does not scale for production, so the database is the first constraint to address. A remote cache matters less here than moving off SQLite, because one node has no other nodes to share warm data with.

Database-only risk: every cache miss and session check lands on the local database, and write locks can slow dashboards during busy periods.
What a remote cache adds: a shared in-memory store that absorbs repeated reads, although the gain on one node is often small and must be measured.
What it adds to operate: another daemon to patch, monitor and back up, plus a network connection, a password and a failure mode for Grafana to handle.
Usually the wrong first step: moving the configuration database to MySQL or PostgreSQL addresses the larger constraint before any cache is considered.

Before adding a cache, confirm whether the instance still uses SQLite and how often the database shows lock waits or slow queries.

Redis, Valkey and Memcached options compared for Grafana

This table compares the three remote cache families a team is likely to consider for a multi-instance Grafana deployment, covering license, high availability, familiarity and client fit. Read each row as a question to put to your legal, platform and operations teams before choosing a backend. The main takeaway is that the license and the Sentinel quorum decide most of the shortlist, so confirm both early and confirm Grafana's current support for each backend in the Grafana docs.

Option	License and source	High availability approach	Operational and client considerations
Redis Open Source 8.x	Redis 8.0 and later can be used under RSALv2, SSPLv1 or AGPLv3, at the user's choice. Redis 7.4 to 7.8 are under RSALv2 or SSPLv1, neither OSI-approved.	Sentinel for failover without Redis Cluster. A robust deployment needs at least three Sentinel instances.	Confirm the license choice with legal before adoption. Existing Redis clients are the usual starting point for teams already running Redis.
Redis 7.2.x and earlier	BSD-3-Clause, per the Redis licenses page.	Sentinel for failover without Redis Cluster. Plan at least three Sentinel instances.	Permissive license, but an older line. Check patch availability and security support for your chosen minor version.
Valkey (BSD-3-Clause)	BSD-3-Clause, forked from open-source Redis before the source-available change. Stewarded under LF Projects, LLC.	Valkey Sentinel for failover without Valkey Cluster. At least three Sentinel instances is the recommended minimum.	Existing Redis client libraries connect without code changes, per the migration guide. Confirm Grafana's current support for Valkey before choosing.
Memcached	Open-source license under which it is distributed. Confirm the exact terms with your legal team.	No built-in replication or failover. Availability depends on how the cache is run and how Grafana handles a lost node.	Simple key-value model with a smaller feature set. Confirm that Grafana's cache usage and your monitoring fit this model before choosing.
Grafana backend support	Not a license question. Support differs by backend and version.	Confirm which backends the Grafana docs list as supported for remote caching in your Grafana version.	Ask your Grafana support path or check the Grafana docs before committing to a backend.
Operational familiarity	Depends on what your team already runs in production.	Staff who already operate Sentinel or a managed service reduce the new skills needed.	A backend your team cannot monitor or patch becomes a risk to Grafana sessions and queries.

What the remote cache holds and what stays in the database

Grafana keeps its durable state in MySQL or PostgreSQL, and that database stays the system of record when a remote cache is added. The cache should hold only data Grafana can rebuild, so the cards below separate what must survive a restart from what can be lost safely.

Dashboards, folders and provisioning state

Dashboard definitions, folders, playlists and their version history are durable configuration. They stay in MySQL or PostgreSQL, so a Redis or Memcached failure never removes a dashboard. Back up the database for this data. Then confirm which dashboards also exist as provisioned files in Git, because those can be recreated after a rebuild without the database copy.

Users, teams and permissions

User records, teams, roles and folder permissions define who can see and change what. Treat them as database-only data. Even with SSO in place, Grafana still stores the user records and permission assignments it needs. Confirm with the Grafana version in use that no permission data exists only in the cache before you test a cache flush.

Login sessions and auth tokens

The high availability guidance relies on database-backed auth tokens so a user can reach any node behind the load balancer. Keep auth tokens in the database unless your version's documentation says otherwise. If sessions are moved to the cache, a cache loss signs users out, which is acceptable only if you agreed that outcome with your users first.

Data source settings and alert state

Data source definitions, stored credentials and alert rules are configuration and stay in the database. Alert state needs the same care. The high availability guidance notes that alerting requires extra configuration to avoid duplicate notifications, so a cache loss must not reset evaluation or silences unexpectedly. Confirm where alert state lives for your version before you run a cache failure test.

Cache entries must be safe to lose

Anything placed in Redis or Memcached must be rebuildable from the database or the data source. A flush, eviction or node restart should cost users only a slower first load. Test this in a quiet window and watch errors and latency in Grafana's own metrics. Review the eviction policy and memory limits so a full cache drops entries in a controlled way.

Confirm the cached object list per version

The exact set of objects Grafana writes to the remote cache depends on the Grafana version and its configuration, so do not assume it from this page. Ask your implementation team to list the cache keys and data types for your version, and record that list next to your backup and sizing plan. Repeat the check after each upgrade, because the set can change between releases.

Setting up a remote cache for a multi-instance Grafana

This sequence moves Grafana's cache off the local database and onto a failover-capable Redis or Valkey deployment shared by every instance. The result is a multi-instance Grafana where all nodes use the same cache and database, and a cache failure causes re-fetching rather than lost configuration.

Confirm the Grafana version and cache backend
The platform team checks the Grafana version in use against the upgrade guidance and the installation docs for that version, then confirms which cache backends and settings that version documents. Record the exact Grafana version, the database engine and the chosen cache engine in a change ticket. Choose the cache engine according to your license policy: Redis Open Source 8.0 and later can be used under AGPLv3, Redis 7.4.x to 7.8.x are offered under RSALv2 or SSPLv1, and Valkey is licensed under BSD-3-Clause. Done when the version and engine decision are written down and approved by the owner of the Grafana service.
Provision MySQL or PostgreSQL before the cache
The database team builds the shared database that holds Grafana's durable state, including users, teams, dashboards, data source settings and alert configuration. Grafana's installation docs say SQLite does not scale for production, and high availability requires MySQL 8.0 or later or PostgreSQL 12 or later. Configure backups and access controls before any Grafana node connects. Done when a test connection from the database host succeeds with the Grafana account and the backup job has completed one successful run.
Deploy the cache with Sentinel or equivalent failover
The platform team deploys a primary cache node with at least one replica and runs three Sentinel instances, which the Redis and Valkey Sentinel docs list as the recommended minimum for automatic promotion of a replica. Place the Sentinels on separate hosts or availability zones so one failure does not remove the quorum. If you choose a different failover tool, confirm with its vendor how it behaves with the client library Grafana uses. Done when a manual failover test promotes the replica and the cache client reconnects without manual changes.
Configure every Grafana instance identically
The platform team sets the cache connection and database connection on each Grafana node in the same way, usually through the configuration file or container environment managed as code. Confirm the exact cache setting names for your Grafana version in its configuration reference, since this sequence does not name them. Every node should point to the same cache endpoint, the same database and the same secret or encryption key settings. Done when a diff of the rendered configuration across nodes shows only host-specific values such as hostname and listen address.
Restart Grafana nodes in rolling order
The operator restarts one Grafana node at a time behind the load balancer and waits for it to pass health checks before restarting the next. Grafana high availability uses two or more active-active servers sharing one database, with database-backed auth tokens so users can reach any node. Keep at least one node serving traffic during each restart. Done when every node reports healthy, the load balancer shows all nodes in rotation, and users who were signed in before the restart can still open dashboards.
Verify cache use and database state
The platform team confirms that Grafana writes cache data to the remote cache and that durable records stay in the database. Inspect cache keys and memory use on the cache nodes, then save a dashboard change through one Grafana node and open it through another. Query or dump the database to confirm that users, dashboards, data sources and alert rules are all present. Done when the cache shows Grafana activity and every durable record found in the database matches what the users see.
Test cache failover without user-visible loss
The operator stops the primary cache node during a maintenance window and watches Sentinel promote the replica. Users should notice only cache misses and re-fetching, not lost sessions or saved changes, so this test must pass before go-live. Record the failover time and any errors in the Grafana logs, and repeat the test after each Grafana or cache upgrade. Done when dashboards load, a saved edit persists, and alert notifications behave as your high availability alerting configuration intends.

Sizing the cache for a multi-instance deployment

Size the remote cache from measured use, not from a guess. The main drivers of cache memory are the number of concurrent viewers, how many dashboards and panels those viewers open, how large each query result is, and how many Grafana instances write to the same cache. Each instance caches results it has fetched, so adding instances behind a load balancer increases the total data held in Redis or Memcached even when the viewer count stays flat. Larger panels with wide time ranges and high-cardinality results also raise the size of every cached entry. Grafana's small-deployment baseline, which the installation docs describe as under 25 concurrent users on 2 cores and 2 to 4 GB of RAM, applies to the Grafana server itself and does not give a cache size. Use it only as a reference point for the Grafana nodes.

Run a representative load test before choosing a memory limit. Replay realistic viewing patterns: peak concurrent users, the dashboards they open most, typical refresh intervals and time ranges, and the alert evaluation load if alerting uses the same instances. Record the memory use of the cache over the full test and at its peak, along with hit ratio and evictions. Confirm the maximum memory setting and eviction policy you plan to use in the documentation for your chosen server, because the names and behavior of these settings differ between Redis, Valkey and Memcached. Then set the memory limit and eviction policy from the measured data, with headroom for growth you have agreed with the business owners of the dashboards.

Revisit the numbers after each change that alters load: a new team on the platform, more alert rules, longer retention of dashboards that query heavy data sources, or an added Grafana node. Watch for evictions that climb during business hours, since they show the cache is too small for the working set, and for a hit ratio that stays low, which suggests the cache is not helping the workload. For the cache itself, plan a failover target and confirm that a cache restart does not stop Grafana from working, because cached data is recreated from the data sources and the configuration database. Ask your implementation partner to document the load test, the chosen limits and the thresholds that trigger a resize.

Security and operations of a shared cache

A remote cache sits between Grafana instances and users' query results, so its exposure, access controls and upkeep matter as much as its speed. The cards below cover the controls to set before go-live and the checks that keep them working after the cache is in production.

Keep the cache on a private network

Place Redis or Memcached on a network segment that only Grafana servers can reach, with no route from user networks or the internet. Grafana instances need to reach the cache on the configured port, and nothing else should. Confirm the bind address and firewall rules on every node, including Sentinel nodes, and test the path from a user subnet to confirm it fails.

Authenticate and encrypt cache connections

Decide whether the cache requires a password or access control list user for Grafana, and whether connections use TLS. Confirm the authentication and TLS options in the docs for the exact product and version you deploy, since the options differ between Redis and Memcached and between release lines. Store credentials in your secrets manager rather than in plain text in the Grafana configuration file.

Limit what the cache holds

Cached query results can contain sensitive operational data, including values from restricted data sources. Treat the cache as a store of that data: limit who can reach it, set expiry on entries, and review which data sources are cached. Ask your security team whether query results from some data sources should bypass the shared cache entirely.

Track the release line you run

Redis and Valkey publish several maintained release lines at the same time, and security fixes ship to more than one line. Record the exact version on each cache node, subscribe to the project's release feed, and schedule patches on your own cadence. Check the license of the chosen Redis release before you upgrade, because Redis 7.4 and later and Redis 8.0 and later are licensed differently.

Test failover with Sentinel quorum

If you use Sentinel for automatic failover, the Sentinel docs recommend at least three Sentinel instances so a quorum can agree on a new primary. Test a failover in a non-production environment, confirm that every Grafana instance reconnects to the promoted node, and check that Sentinels are spread across failure domains. Repeat the test after each upgrade.

Monitor cache health beside Grafana

Watch the cache with the same discipline as the Grafana database. Track memory use, eviction counts, connected clients, latency and replication status, and set alerts on them. Correlate cache metrics with Grafana's own query latency so that a cache problem is not mistaken for a slow data source. Confirm which metrics your cache product exposes before you build dashboards.

Questions teams ask before moving Grafana's cache

Does a single Grafana instance need a remote cache with Redis or Memcached?

No. A single Grafana instance can run with its cache in the database, and a remote cache mainly pays off when several Grafana instances need to share cached results. The reason to add one is usually a shared cache across nodes, not raw speed on a lone server. Before deciding, check whether your query load and cache hit patterns actually create contention in the database. Grafana's own metrics and your database monitoring are the right evidence to review first. If you run one instance and the database is comfortable, a remote cache adds a component to operate without a clear gain.

What does moving Grafana's cache to Redis or Memcached cost, and what drives it?

The cost has three parts: the design and configuration work, the hosting of the cache service, and the ongoing operation of that service. Hosting and operation recur every month, while the migration work is largely one-time. The main drivers are the number of Grafana instances, the expected query volume, how much cache memory you need, whether you require high availability for the cache, and whether you host it yourself or use a managed service. Ask any partner for a quote that separates design, configuration, testing, cache hosting and handover, and states which items recur. A fixed-scope written agreement makes these components easier to compare.

How long does a remote cache change take, and what does the timeline depend on?

The timeline depends on how many Grafana instances you run, how the cache must be made highly available, and how much testing your change window requires. Time is also spent confirming the cache platform choice, network access, secrets handling and rollback steps. Teams with an existing Redis or Valkey service and a test environment that mirrors production usually finish faster than teams that must stand up new infrastructure. Ask for a written schedule with milestones for design, build, test and cutover, and confirm which steps depend on your change approval process.

What must our team provide before a Grafana cache project can start?

Most of the inputs are access and decisions rather than software. Expect to provide:

Administrative access to the Grafana configuration and to the database that Grafana already uses
A place to host the cache, either your own servers, Kubernetes or a managed service you approve
Network rules that allow Grafana instances to reach the cache port and any Sentinel or failover endpoints
Secrets handling for cache credentials, plus a staging environment for testing

Confirm with your security team whether the cache may hold any sensitive query results, since that affects encryption and access settings.

Can an internal platform team configure a Grafana remote cache alone?

Often yes, if the team already runs Grafana and operates a Redis or Valkey service, and has time to test failover. The harder parts are sizing the cache for multiple instances, deciding how it fails over, and proving that a cache outage does not break dashboards or alerting. Teams without recent experience with cache operations usually benefit from an outside review of the design before cutover. Compare the internal effort, including on-call coverage and the skills needed for failover testing, against the cost of a scoped engagement. Either way, document who owns the cache after handover.

What does a Redis licensing change mean for choosing a cache?

Redis changed its licensing: Redis 8.0.0 was published on May 2, 2025, and Redis Open Source 8.0 and later can be used under a license of your choice among RSALv2, SSPLv1 and AGPLv3, according to the Redis licenses page. Redis 7.4.x to 7.8.x are under the dual RSALv2 or SSPLv1 license, which is not OSI-approved, while Redis 7.2.x and earlier remain under BSD-3-Clause. Valkey 9.0.0 was published on October 21, 2025, and Valkey is licensed under BSD-3-Clause and governed under the Linux Foundation. Have your legal team review which Redis version and license fit your policy before you choose, and confirm the terms with the vendor.

How DeployOpen scopes and delivers a Grafana cache change

DeployOpen treats a Grafana remote cache change as a planned infrastructure change, not a configuration tweak. We scope the cache boundary, build and test it in your environment, and hand over documentation your team can operate from.

How we scope

Inventory which Grafana instances share a database and where caching would sit in the request path
Agree in writing which cache engine, deployment topology and failover design the engagement covers
Confirm the Grafana version, Redis or Valkey version and licensing position before any work starts
Record which items stay in the database and which move to the remote cache, with the reasons

How we build

Build the Redis or Memcached tier in the infrastructure you control, with network access limited to Grafana nodes
Configure every Grafana instance against the same remote cache settings and confirm they behave consistently
Test failover, restart and cache loss scenarios, and record what users see during each one
Measure database load and dashboard response before and after the change using Grafana's own metrics

How we hand over

Deliver a written runbook covering configuration keys, sizing assumptions, monitoring points and rollback steps
Walk your operations and platform team through failover behavior and what a cache flush means for users
Store configuration and deployment files in your repository so the setup can be rebuilt and reviewed
Document the open decisions your team must confirm, such as memory limits and eviction policy

How we support

Support is available as a retainer for version upgrades, cache tuning and incident follow-up after handover
Retainer scope, response expectations and review cadence are agreed in writing before the retainer starts
Re-test the cache path after each Grafana minor or patch upgrade and after any change to the cache tier
Quotes follow from the written scope, so ask for each item (build, testing, handover, retainer) to be priced separately