Redis and Valkey Support Providers Compared

You can buy commercial support for open-source Redis without buying Redis Enterprise. Those are two separate decisions, even though they usually arrive as one conversation.

Four categories of provider exist, they are genuinely different, and the right answer depends on what you need during an incident rather than on which has the largest logo.

This table was built from each provider's own public pages on 22 October 2026, in US dollars; list prices vary by region and commitment, and response times are defined differently by each provider, so read the contract definition of P1 before comparing. Sources: Redis software support policy, Redis pricing, ElastiCache pricing, ElastiCache SLA, Azure Managed Redis, Azure retirement FAQ, Aiven for Valkey, Aiven support, Percona Valkey support and Ksolves Redis support.

Redis support pricing splits three ways: percentage-of-spend fees on cloud services (AWS Support and Aiven take the greater of a minimum or a share of monthly charges), annual plans sold on request by the vendor, and quote-only contracts from independents such as Percona, Ksolves and AceMQ. Only the first group publishes numbers. The cost ranges behind each model are in Redis support pricing.

For a 3am Redis incident, compare the published first-response time and who answers, not the logo. Redis Ltd lists 15 minutes at its Enterprise package for paid Redis Software, Aiven 15 minutes at Premium, Percona and AceMQ as fast as 15 minutes, Ksolves 30 minutes for critical issues; cloud providers cover their managed service only. Ask each one to name the escalation path in writing. AceMQ runs a single escalation path across Redis and RabbitMQ for a global quantitative trading firm, and describes its 24/7 Redis support scope in full.

• The vendor. Redis Ltd supports its own commercial products, and its engineers know the code as well as anyone. The orientation is naturally toward its commercial offering, so if your intention is to stay on open-source Redis indefinitely, be clear about that early. The comparison is in Redis Enterprise support vs community.
• Cloud providers. If you run a managed Redis-compatible service, support comes with it and is generally good — within the boundary of that service. It stops where your application and your architecture begin, and it does not travel if you move platform.
• Generalist open-source support firms. Companies supporting dozens or hundreds of open-source packages, Redis among them. Genuinely useful when you want one contract covering a broad stack. The trade-off is depth: breadth that wide rarely comes with a Redis specialist on the rota.
• Independent specialists. Firms that support Redis and Valkey specifically, wherever you run them — on-premises, cloud, self-managed. Narrower coverage, deeper knowledge, and no incentive attached to which distribution you run.

Who answers at 3am, and how much Redis do they know?

That is the whole comparison, because Redis incidents are unforgiving of shallow familiarity. Memory pressure triggering eviction of data the application assumed was durable. A failover that half-completed and left clients pointed at a demoted node. Client-side timeouts against a server that is objectively healthy — an investigation that goes badly wrong if the first responder does not know to check connection pooling before the broker.

Those are covered in eviction policy, high availability patterns and client timeouts with a healthy server. An engineer who has seen each of them before resolves in an hour what a generalist works through overnight.

A quick and genuinely revealing test: ask how the provider handles Valkey.

Since the fork, estates increasingly run one, the other, or both. The operational surface is largely shared — memory management, replication, failover, persistence, client behavior — so a provider who really knows Redis should support Valkey comfortably and be able to name specifically where behavior has diverged.

Two answers should give you pause. "We don't do Valkey" suggests the practice is tied to a vendor relationship rather than to the technology. "They're identical" is not true and gets less true with each release. The useful answer is a specific one. More detail in Valkey support options.

Break-fix alone is the least valuable half of a support contract. A useful one also includes:

• Incident response with a defined out-of-hours path and a named escalation — see Redis incident response.
• Memory and eviction design, before the eviction happens rather than after.
• Replication and failover architecture, including an actually-executed failover test rather than a documented one.
• Upgrade planning across versions and, where relevant, across forks.
• Periodic health checks — see what a Redis health check covers. These prevent incidents, which is why cheaper break-fix contracts often cost more overall.

AceMQ supports open-source Redis and Valkey in production, wherever you run them. See how we support Redis or get in touch.

Can I get commercial support for open-source Redis without buying Redis Enterprise?

Yes. Generalist open-source firms, database consultancies and independent specialists all support open-source Redis on infrastructure you already run.

What are the actual categories of provider?

The vendor, cloud providers bundling support with a managed service, generalist open-source support firms, and independent Redis and Valkey specialists.

How do I choose between them?

Ask who answers during an incident and how deep their Redis knowledge goes. Breadth and depth trade off directly.

Does the licensing change affect who can support Redis?

No. It changed distribution and prompted the Valkey fork; it did not restrict who may provide support services.

Should a provider support Valkey too?

Yes, and it is a good filter. They should support both and name specifically where the two have diverged — not refuse, and not claim they are identical.

What should be in scope?

Incident response with an out-of-hours path, memory and eviction design, replication and failover, upgrade planning, and periodic health checks.