Redis vs Memcached: when a pure cache is enough and when it is not
Choose Memcached when you need a shared, disposable cache of simple key/value pairs and nothing else. Choose Redis when the shared store must hold data structures, persist across restarts, replicate to other nodes, or fail over automatically with Sentinel. Memcached is BSD-3-Clause licensed, multithreaded, uses non-blocking network I/O, and never writes to disk, so its footprint and operating model stay simple. The decision then turns on three questions: how much data loss you can tolerate, what the license terms mean for internal and hosted use, and which Redis version you would deploy.
Start with durability. If losing cached entries is acceptable and the application can rebuild them from its source of truth, Memcached's memory-only design removes a class of operational work. If session state, rate-limit counters or queues must survive a node restart, Redis persistence and replicas become relevant, and a robust failover design needs at least three Sentinel instances. Confirm the persistence and replication settings in your own configuration and test a restart and a failover before you rely on either outcome. Do not assume that a cache that works well in staging will behave the same way during a node loss in production.
Then check the license and the version line. Redis 8.0 and later are available under your choice of RSALv2, SSPLv1 or AGPLv3, while Redis 7.4.x to 7.8.x remain under RSALv2 or SSPLv1, which are not OSI-approved. Redis 7.2 and earlier stay under BSD-3-Clause. If you run unmodified Redis 7.2 or earlier, the Redis licenses page says you see no impact, but offering modified Redis code as a network service carries source-sharing duties. If you need a permissive Redis-compatible store on 7.4 or later, Valkey is the BSD-3-Clause option under Linux Foundation governance. Existing Redis client libraries connect to it without code changes, but data files from Redis 7.4 and later need a different migration method, so plan that work before you choose.
Which platform fits which scenario
This table maps common Redis and Memcached scenarios to the platform that usually fits better, and names the condition that would change the answer. Read each row as a starting point, then check the license and feature notes against your own workload and edition choice before you decide.
| Scenario | Better fit | Why and when it changes |
|---|---|---|
| Plain shared cache for database offload | Memcached | A pure key/value cache that never writes to disk keeps the operating model simple. This changes if you later need data structures, persistence or replication for the same cache tier. Confirm Memcached's eviction, memory and client behavior against your own load tests. |
| Session storage that must survive a restart | Redis or Valkey | Redis persists data to disk through RDB snapshots and AOF files, which Memcached does not do. Memcached sessions are lost on restart. Confirm the persistence settings and recovery time you need in your own environment before relying on them. |
| Queues, counters or sorted sets | Redis or Valkey | Lists, sorted sets, streams and atomic counters are native Redis data structures. Memcached offers only simple key/value operations, so application logic would move into your code. Stay with Memcached only if the application can tolerate that rewrite. |
| Hosted service built on modified Redis code | Valkey or Memcached | Redis 8.0 and later can be used under AGPLv3, RSALv2 or SSPLv1, and the Redis licenses FAQ says modified code run as a network service must have its source made available to that service's users. Valkey under BSD-3-Clause avoids that obligation. Have counsel confirm the terms that apply to your version and distribution. |
| Permissive license requirement | Memcached or Valkey | Memcached is BSD-3-Clause and Valkey is BSD-3-Clause. Redis 7.4 and later are under RSALv2 or SSPLv1, which are not OSI-approved. Redis 8.0 and later also offer AGPLv3, which is copyleft. Confirm the license your legal team accepts before choosing. |
| Existing Redis 7.2 or earlier estate | Valkey | Valkey is compatible with Redis OSS 7.2 and earlier, and moving from those versions is described as effectively an upgrade, with existing client libraries working without code changes. Memcached would require rewriting application cache calls and data handling. |
| Existing Redis 7.4 or later estate | Stay on Redis or plan a dedicated migration | Redis Community Edition 7.4 and later write data files that Valkey cannot read, so the migration guide's standard methods do not apply directly. Ask your vendor or test a migration method outside the guide before moving to Memcached or Valkey. |
| Redis high availability needs | Redis or Valkey with Sentinel | Redis Sentinel and Valkey Sentinel both provide automatic failover, and the docs recommend at least three Sentinel instances. Memcached has no built-in replication, so high availability is designed in the application layer. Confirm the failover design your application requires. |
How Redis and Memcached are built and what that means for operations
Redis and Memcached both keep data in memory, but they differ on what they store, whether they write to disk, and how they stay available. Each card below names one of those differences and the operational consequence a team has to plan for before choosing between them.
Data model and what gets stored
Memcached stores opaque key/value pairs with no server-side structure, so every change to a value is a full read and write by the client. Redis stores strings, hashes, lists, sets, sorted sets and streams, plus modules such as JSON and probabilistic structures, which lets the server run operations on the data itself. Check which structures your application actually needs, because a pure key/value workload gives Memcached little to lose and Redis a larger surface to patch and monitor.
Persistence and node restarts
Memcached never writes to disk, so a restart or crash empties the cache and clients refill it from the source of truth. Redis can persist data through RDB snapshots and an append-only file, so a restart may recover recent state, but the amount lost depends on the persistence settings you choose. Decide up front whether losing the cache is acceptable, and test how long the backing database takes to absorb the refill traffic.
Replication and Sentinel failover
Redis replicates from a primary to replicas, and Sentinel promotes a replica automatically when the primary fails. Redis Sentinel documentation recommends at least three Sentinel instances for a robust deployment, and Valkey Sentinel carries the same guidance. Memcached has no built-in replication, so confirm with the project and your client library how any redundancy is handled, and do not assume Redis failover behavior applies to it.
Redis Cluster as a separate path
Redis Cluster shards data across hash slots and is a different design from Sentinel, which protects a single primary. Choosing Cluster changes client requirements, multi-key operation limits and how you scale, so it should be decided before the application is built. Confirm with your client library that it supports Cluster routing, since sharding in Memcached is typically handled by the client, and that approach needs its own review.
Threading and network I/O
Memcached is a multithreaded, event-based server that performs non-blocking network I/O, which suits high connection counts for simple reads and writes. Redis processes commands on a single main thread for data operations, with additional threads handling some network and background work. Measure your own request mix and connection pattern rather than relying on general throughput claims, and confirm current threading behavior in the release notes for the version you deploy.
Licensing and version lines
Memcached is BSD-3-Clause licensed. Redis Open Source 8.0 and later is available under RSALv2, SSPLv1 or AGPLv3 at your choice, while Redis 7.2 and earlier remain BSD-3-Clause. Valkey, a BSD-3-Clause fork, maintains several release lines at once, so check which line your distribution ships. Patch cadence is an operating cost on every side, so confirm the support window for the exact version you plan to run.
Redis vs Memcached on features, persistence and high availability
This table compares Redis and Memcached on license, data types, persistence, high availability, modules and commercial offerings. Where the supplied record is silent on Memcached, the cell tells you what to confirm with the Memcached project. Memcached suits pure caching, while Redis suits workloads that need richer data types, disk-backed data or automatic failover.
| Capability | Redis | Memcached |
|---|---|---|
| License | AGPLv3, RSALv2 or SSPLv1, chosen by the user from Redis 8.0 onward | BSD-3-Clause, a permissive license |
| Client library support | Redis client libraries are widely used; confirm your language client's version support | Confirm client library support for your language with the Memcached project |
| Supported operating systems | Linux, macOS, OpenBSD, NetBSD and FreeBSD; Windows only through Docker | Confirm supported platforms with the Memcached project |
| Data types | JSON, time series, probabilistic structures, vector sets (beta) and the Redis Query Engine for vector, full-text and geospatial search | Simple key/value cache |
| Persistence | Data can be written to disk; confirm durability settings for your version | None. Memcached never writes to disk |
| High availability | Sentinel provides automatic failover to a replica; at least three Sentinels recommended | Confirm replication and failover options with the Memcached project |
| Modules | Modules built on the RedisModule_ API; check each module's license | Confirm extension and plugin options with the Memcached project |
| Commercial offerings | Redis Software (self-managed) and Redis Cloud; neither is open source | Confirm vendor offerings and support options with the Memcached project |
What each license and edition means for internal and hosted use
Memcached is licensed under BSD-3-Clause, a permissive license that allows internal use, modification and redistribution, including inside commercial products, as long as the copyright notice and license text are kept. Nothing in the license requires you to publish modified code when you run it as a service for your own users or customers. The obligations are light, but the cache itself does not persist data, so the license question is only one part of the decision.
- Internal use: You can run, modify and deploy Memcached across your own infrastructure without paying a license fee to the project.
- Modified code as a network service: BSD-3-Clause does not require you to release source for modifications, so the obligation is limited to keeping the notice intact.
- What is paid for: The license is free. Costs come from your own staff, hosting, monitoring and any support contract you buy from a third party.
- Commercial distributions: Third-party vendors may package or support Memcached, and their terms govern that support, not the BSD license.
- Persistence: Memcached never writes to disk, so data protection depends on your application design, not on the license.
Confirm with legal counsel that the notice and attribution requirements are met in any product you ship, and check which support terms your procurement team needs.
Redis 7.2.x and earlier remain under BSD-3-Clause, so the permissive obligations described for Memcached apply to these versions. The Redis licenses FAQ states that teams moving from Redis 7.2 or earlier with unmodified Redis artifacts see no impact from the later license change. These versions are the lowest-friction choice on license grounds, but they are older lines, so confirm the support window and security patch policy you need before choosing them.
- Internal use: You may run and modify these versions under BSD-3-Clause without a license fee.
- Modified code as a network service: No source disclosure is required under BSD-3-Clause, though the copyright notice must be retained.
- Unmodified artifacts: The Redis licenses FAQ says teams using unmodified 7.2 or earlier artifacts see no impact from the 2024 change.
- Paid offerings: Redis Software and Redis Cloud are separate products with their own terms, and they are not implied by running these older versions.
- Support window: Check with Redis Ltd. or your provider which patch releases remain available for the line you deploy.
Ask legal counsel whether any internal patches you carry would change the position, and confirm the support lifecycle with the vendor before you commit.
Redis 7.4.x through 7.8.x, then called Redis Community Edition, are offered under a dual license of RSALv2 or SSPLv1. Neither license is OSI-approved, so these versions do not qualify as open source under the OSI definition. The licenses restrict some uses that the BSD-licensed lines allow, and the obligations differ depending on whether you run the software internally or offer it to others as a service.
- Internal use: You may generally use the software internally, but read the RSALv2 and SSPLv1 terms to confirm your use case, including any competitive or hosted restrictions.
- Modified code as a network service: SSPLv1 can require you to release source for the whole service stack if you offer it to third parties, so this is the area that needs legal review first.
- Paid offerings: Redis Software adds compliance, reliability and resiliency features for self-managed deployments, and Redis Cloud is a managed service on AWS, Google Cloud and Azure. Neither is open source.
- Version boundary: The Redis licenses page places these versions in the dual RSALv2 or SSPLv1 group, and migration from them to Valkey needs a different method than the one for 7.2 and earlier.
- Compatibility: Valkey's migration guide warns that data files from Redis Community Edition 7.4 and later are not compatible with Valkey.
Have counsel review the RSALv2 and SSPLv1 texts against your intended internal and hosted use before you deploy any version in this range.
Redis Open Source 8.0 and later can be used under a license of your choice among RSALv2, SSPLv1 and AGPLv3, effective from the general availability release of Redis 8. Redis Ltd. has said it plans to keep Redis Open Source under AGPLv3 because license stability is essential for the community. The choice matters most for hosted offerings, and it also determines which bundled features you can use, since some closed-source components are restricted to RSALv2.
- Internal use: Running Redis 8 internally is possible under any of the three licenses you choose, and the choice should follow your legal review.
- Modified code as a network service: Under AGPLv3, you must make modified source available to users who interact with the modified service over a network. SSPLv1 has broader obligations for hosted offerings.
- Bundled features: The Intel SVS-VAMANA optimizations (LeanVec and LVQ) are closed source and can only be used with Redis Open Source distributed under RSALv2, not under AGPLv3 or SSPLv1.
- Paid offerings: Redis Software for self-managed compliance and resiliency features, and Redis Cloud for managed deployments on AWS, Google Cloud and Azure, are sold separately and are not open source.
- Latest line: The Redis releases page lists 8.10.0 as the current line, but confirm the version and patch level you deploy against that page.
If you use vector optimizations, confirm with counsel that RSALv2 is the license you need, because that choice removes the AGPLv3 option for those features.
Valkey is licensed under BSD-3-Clause and was forked from open-source Redis right before Redis moved to source-available licenses. It is an open community project under LF Projects, LLC, backed by the Linux Foundation, which holds the Valkey trademarks. Because the license is permissive, the obligations for internal use and for offering modified code as a service are light, and the governance is set by a foundation rather than a single company.
- Internal use: You can run, modify and deploy Valkey under BSD-3-Clause without a license fee to the project.
- Modified code as a network service: BSD-3-Clause does not require you to publish modifications, though the copyright notice must be retained.
- Compatibility: Valkey is compatible with Redis OSS 7.2 and earlier, and migration from those versions is effectively an upgrade, according to the migration guide.
- Paid support: Support comes from providers and cloud vendors that offer Valkey, and their terms govern that support, not the Valkey license. The project participants list includes several cloud providers.
- Feature gap: Valkey does not include the Redis-licensed bundled features described for Redis 8, so check each module and feature you need against Valkey before you migrate.
Ask counsel to confirm the BSD-3-Clause obligations for your product, and confirm with your chosen Valkey provider which support and feature terms apply.
What drives the running cost of each option
The largest recurring cost for Redis is memory, because the whole dataset lives in RAM. Plan capacity from the working set you expect, not the total data size, and budget for replicas, which hold a full copy of the data. If you run Sentinel for failover, the supplied guidance calls for at least three Sentinel instances, so the node count rises before any data grows. Memcached also keeps its data in memory and never writes to disk, so its memory line is similar in kind, but it has no replica or Sentinel layer to pay for. Ask each vendor or partner to state the node count, memory per node and replica count they assume, and ask how that changes at your peak request rate.
Staff time is usually the larger hidden cost. Redis asks someone to test Sentinel failover, monitor replication lag, plan upgrades across release lines and watch security releases. Memcached has far fewer moving parts, so its operating time is mostly capacity planning and monitoring. Upgrades also carry a license review step for Redis: moving between the 7.2 line and 7.4 or later, or taking an 8.x release, changes which license terms apply, and legal review of hosted or modified use can take time that does not appear on an invoice. Confirm internally who owns that review before you pick a version.
Most of the one-time cost sits in migration and client testing, and it differs by path. Moving from Redis 7.2 or earlier to Valkey is described as effectively an upgrade, while Redis 7.4 and later produce data files that are not compatible with Valkey, so that path needs a different method. Quotes should list each one-time item separately: migration work, client library testing, license review and any load testing. Recurring items should be listed separately with their basis, such as support hours, managed service tiers or retainer scope. Neither vendor documentation nor the supplied facts give prices or durations, so request figures from each vendor and a written, fixed scope from DeployOpen before comparing totals.
How to move from Memcached or Redis 7.2 to Redis or Valkey
This sequence takes a team from an unknown set of cache clients to a tested target, a chosen migration method and a cutover that is checked before traffic moves. The output is a migration record that the platform, security and application owners have each signed off.
Inventory clients, data types and cache behavior
The application team lists every service that connects to the cache, the client library and version each one uses, and the Redis data types, modules and commands in use. For Memcached sources, the same team records whether any value is treated as authoritative rather than as a cache. Platform engineering checks the source version, whether persistence is enabled and whether the deployment uses Sentinel or Cluster. The step is done when every client and data type has an owner and a documented reason for being in use, and the application owner has confirmed in writing whether Memcached data can be repopulated after cutover.
Choose the target and its license
Decide between Redis 8 or later, Valkey, or Memcached itself, based on the features the inventory found. Redis 8 and later can be used under AGPLv3, RSALv2 or SSPLv1, so the legal owner records which license applies to internal use and to any modified code offered as a network service. Valkey is BSD-3-Clause and is the permissive option for a Redis 7.2 or earlier source. Teams that depend on JSON, time series, probabilistic structures or the Redis Query Engine should confirm that the chosen target supports them before going further. The step is done when the decision, its license basis and any unsupported feature are written into the migration record.
Confirm the source version and file compatibility
The platform team confirms the exact source version from the running servers, not from the deployment template. Redis OSS 7.2 and earlier, and Valkey 7.2 or later, produce RDB and AOF files that the Valkey migration guide describes as compatible. Redis Community Edition 7.4 and later produce data files that the guide says are not compatible with Valkey, so those sources need a method the guide does not cover. The team should ask the vendor or test in a non-production environment how such a source will move before committing to a date. The step is done when the source version is recorded and the migration path for that version is named.
Select the migration method
The team chooses one of the four methods documented in the Valkey migration guide. Copying an RDB snapshot suits a short write window and a dataset the team can restore into a fresh server. REPLICAOF replication followed by promotion keeps the source running while the target catches up, then moves writes at a controlled point. Key-level MIGRATE suits moving a selected subset of keys. For clusters, adding Valkey nodes as replicas and promoting them with CLUSTER FAILOVER is the documented path. The platform engineer writes the chosen method, the rollback point and the owner of each action. The step is done when a peer has reviewed the method against the inventory.
Rehearse the migration in a staging environment
The platform team runs the chosen method against a copy of production data in a non-production environment that matches the topology, including Sentinel or Cluster layout and the client connection settings. The application team runs its test suite and a set of read and write paths against the target. The team measures error rates, latency and memory use against the source during the rehearsal and records any command that behaves differently. The security team checks authentication, TLS and network exposure on the target. The step is done when the rehearsal completes with no unexplained differences and the results are attached to the migration record.
Rebuild Sentinel, monitoring and license records
Several items do not move with the data and must be rebuilt for the target. The team recreates Sentinel configuration, which for Valkey requires at least three Sentinel instances in a robust deployment, and it updates health checks, dashboards, alert thresholds and backup jobs that point at the old service. Licensing records are updated to show the license chosen in step two and any obligations for modified code. Runbooks, secrets and firewall rules are reviewed for the new endpoints. The step is done when a checklist shows each rebuilt item with an owner and a passing test.
Cut over and verify live traffic
The operations team performs the cutover during the window agreed in the rehearsal, using the method and rollback point recorded in the migration plan. Client code that uses existing Redis client libraries should connect without code changes, but the team confirms this in production by watching connection errors and command failures. Application owners verify key behavior on live paths and watch for cache miss spikes. For Memcached sources, the team checks that repopulation works as the application owner confirmed. The step is done when the target serves all traffic, the rollback point is no longer needed, and the source is decommissioned under the recorded retention plan.
Document the outcome and review the target
The team closes the migration record with the final method, the data checks performed, any feature differences found in rehearsal and the license basis under which the target runs. It schedules a review of the target's maintenance status, since Valkey and Redis publish multiple release lines and version support can change. Security owners add the target to the regular patch and vulnerability process. Where the team wants outside review of the cutover or its controls, it should ask a security testing provider for a written scope before work starts. The step is done when the record is signed off by the platform, application, security and legal owners.
What implementing each option involves and where projects run long
Memcached is the smaller job, but it is not a no-op. The work starts with client configuration: every application that talks to the cache needs its server list, timeouts and connection handling set explicitly, and the team should confirm how its chosen client library distributes keys across nodes. Sizing follows, based on the working set you expect to hold in memory, since Memcached never writes to disk and any eviction or restart means the data is simply gone. Cache key design is where teams often underinvest. Keys must be deterministic, namespaced by version or environment, and specific enough that one service cannot overwrite another's values. Hit-rate testing closes the loop: run representative traffic against a staging cache, measure hit ratios and the load that falls back to the database on misses, and only then size production.
Redis or Valkey asks for more decisions up front. The data model comes first: choosing between strings, hashes, sorted sets, streams or module-backed types determines memory use, eviction behavior and what a failover can lose. Persistence settings follow, covering whether RDB snapshots, the append-only file or both are enabled, and how much data loss the business accepts after a crash. A Sentinel layout is the next item. Sentinel needs at least three Sentinel instances for a robust deployment, placed so that a single host or rack failure cannot take out a majority. Failover tests then have to be run on purpose, by stopping the primary under load, confirming that a replica is promoted, and checking how long clients take to reach the new primary. Client reconnection behavior is part of that test, because some libraries reconnect cleanly to a new primary and others keep writing to the old one until restarted.
Questions buyers ask before choosing between Redis and Memcached
Can Memcached replace Redis for user sessions?
Only if losing sessions is acceptable. Memcached is a multithreaded key/value cache that never writes to disk, so a restart or eviction removes every session it holds. Redis can persist data to RDB snapshots or AOF files and offers replication and Sentinel failover, which matters when sessions must survive a node failure. Teams with short-lived, re-creatable sessions often run Memcached happily. Teams that treat sessions as state should test the failure path in staging, including what users see after a failover, before they decide.
What does Redis licensing mean for a SaaS product?
Redis Open Source 8.0 and later lets you choose among RSALv2, SSPLv1 and AGPLv3, so the obligations depend on the option you take. The FAQ on the Redis licenses page says teams moving from Redis 7.2 or earlier with unmodified artifacts see no impact, while teams that offer modified Redis code as a network service must make the modified source available to that service's users. Your legal team should read the licenses and confirm how your deployment, modifications and hosted offering map to each option. Memcached's BSD-3-Clause license carries no comparable network-service condition.
Is Valkey a drop-in replacement for Redis 7.2?
For most Redis 7.2 deployments, Valkey 7.2 is designed as a compatible successor. Valkey's migration guide says existing Redis client libraries connect without code changes, it reads and writes RDB and AOF files compatible with Redis OSS 7.2, and modules written for the RedisModule_ API work. It is also BSD-3-Clause licensed and maintained under the Linux Foundation. Compatibility still needs proof in your environment, so run your client test suite, your persistence restore tests and your failover drills against Valkey before you cut over. Ask for that evidence in writing.
What does Redis migration effort depend on?
The main driver is the version you run today. Valkey's migration guide describes moving from Redis OSS 2.x through 7.2.x to Valkey 7.2 or later as effectively an upgrade. It warns that Redis Community Edition 7.4 and later write data files that Valkey cannot read, and the guide does not cover that path, so those deployments need a different method. Other drivers include the number of modules and commands in use, cluster topology, the size of your datasets, how much downtime your service tolerates, and how many client libraries you run. Ask the implementer to inventory all of these before estimating anything.
How many Sentinel instances does a Redis high availability setup need?
The Redis Sentinel documentation says a robust deployment needs at least three Sentinel instances, and Sentinel provides automatic failover that promotes a replica to primary when Redis Cluster is not in use. Three Sentinels allow a quorum to agree on a failover even when one Sentinel is down. Place them on separate hosts or failure domains, or a single rack failure can remove the quorum. Valkey Sentinel follows the same recommendation of at least three instances. Your team should also test client reconnection behavior, because Sentinel failover only helps if clients find the new primary.
What must our team provide before a Redis or Valkey project starts?
You need people who understand your application's cache usage, including key patterns, expiry rules, data size and failure tolerance, plus someone who can operate Linux hosts, networking and backups. You also need a staging environment that mirrors production topology closely enough to test failover and restores, and a client test suite that exercises every command and library your applications use. Without the test suite, compatibility claims cannot be checked. A written list of owners, change windows and rollback steps keeps the project on schedule. DeployOpen's fixed-scope engagements set these inputs out in writing before work begins.
Can our team run the Redis or Valkey migration itself?
A capable platform team can, provided it has time, the skills listed above and a tested rollback path. The work usually involves choosing a migration method, such as an RDB copy, replication with promotion, key-level MIGRATE or adding replicas to a cluster, and proving each step in staging. Teams that have not operated stateful caches under failure may find the failover tests the hardest part. An external implementer can plan, implement, document and hand over the result, or support you through a retainer after go-live. Decide based on your staff's current workload and the risk your service can absorb.
What should we ask for in a quote for a Redis or Valkey project?
Ask for a written scope that names the current version, the target (Redis Open Source under a chosen license, or Valkey), the migration method, the node count and high availability design, and which applications and client libraries are covered. The quote should list deliverables such as the test plan, runbooks, backup and restore verification, and handover documentation. Ask which items are one-time work and which recur, such as support retainers, upgrades and continuous testing. DeployOpen does not publish a price list, so the quote follows from the written scope. Compare quotes on identical scope, not on headline totals.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including cache layers. We start by settling whether your workload needs Redis data structures, persistence or replication, or whether a pure cache such as Memcached fits, then build and hand over the chosen platform in your environment.
How we scope
- Written scope that records which caching workloads need Redis data structures and which are pure key/value caching
- Licensing review of how your team uses Redis Open Source, including internal use and any modified code offered as a network service
- Agreed deliverables, timeline and exclusions before any work starts, with ongoing support available as a retainer
How we build
- Deployment of the selected platform in your cloud account, data center or air-gapped network, with the failover design you choose
- Client library compatibility checks and configuration of persistence, memory limits and eviction for your workload
- Security testing of exposed interfaces and access controls, with results tracked against the agreed scope
How we hand over
- Runbooks covering failover, backup and restore, version upgrades and any migration from Redis 7.2 or earlier to Valkey
- Documentation of architecture, configuration keys and evidence your auditors or compliance team may request
- Knowledge transfer sessions with your platform and security engineers so operations stay in your hands
How we support
- Retainer options for patching, version upgrades and monitoring of the chosen cache platform after handover
- Periodic retesting of the cache deployment as client libraries, versions or network exposure change
- Support scoped in writing, so response expectations and upgrade work are clear before the retainer begins
