Redis Enterprise Software pricing: how does shard-based licensing work and how do I get a quote?

Redis Enterprise Software uses a shard-based licensing model designed to map cost directly to the performance and capacity you actually need. Instead of paying by node or by vague “tier,” you license the number of Redis shards your databases use across a cluster, then scale that up or down as your workloads grow.

Quick Answer: Redis Enterprise Software (often called “Redis Software”) is licensed primarily by the number of Redis shards you run in your cluster. To get an exact price, you’ll work with Redis sales to size your shard count and deployment (on‑prem, hybrid, or in your own cloud) based on memory, throughput, and availability requirements.

The Quick Overview

What It Is: A shard-based licensing model for Redis Enterprise Software, where you pay for the number of Redis shards rather than per-node or per-database.
Who It Is For: Platform teams and architects running Redis on their own infrastructure (on‑prem or in their own cloud accounts) who need high performance, multi-tenant clusters, and enterprise-grade features.
Core Problem Solved: It gives you predictable pricing tied to real capacity and throughput while letting you scale to hundreds of databases and shards per cluster without re-architecting your licensing.

How It Works

Redis Enterprise Software is built around clusters that can host many databases. Each database is composed of one or more Redis shards. Shards are the core unit for performance and scaling—and they’re also the unit for licensing.

Operationally:

Your cluster runs on a set of nodes (VMs, bare metal, or Kubernetes).
Each database in Redis Software gets a RAM quota and can span one or more shards.
Shards are placed across your nodes based on a shard placement policy (dense or sparse) and can be resharded online for more throughput.
Licensing counts the number of shards in use, taking into account high availability replicas where relevant.

In practice, your licensing conversation is about how many shards you need today (and likely growth over 12–36 months), plus which enterprise features (Active-Active geo distribution, Flash tiering, multi-AZ HA, support) you require.

Sizing & Architecture:
You and Redis solution engineers estimate memory, throughput, and HA needs, then translate that into shard count. For example, a multi-tenant cluster with 50 apps might start with 3–5 shards per critical database and 1–2 for smaller ones, plus replicas.
Shard-Based Subscription:
Redis pricing is then expressed as a subscription for some number of licensed shards, typically per year. This can include different shard types (RAM-only, RAM+Flash) and may have minimums based on support and deployment scale.
Operate & Scale Without Downtime:
As your workloads grow, Redis Software lets you reshard databases online to add shards and scale throughput while maintaining sub-millisecond latencies. When you need more shards than your current license, you adjust the subscription; resharding itself doesn’t require downtime.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Shard-based licensing	Licenses Redis Enterprise Software by the number of shards in your cluster.	Aligns cost with real capacity and throughput, not just node count.
Multi-tenant clusters	Host 100s of databases per cluster, each with its own shard layout and RAM quota.	Consolidate teams and apps on one Redis platform while keeping isolation and predictable performance.
Online resharding & placement policies	Scale databases into more shards without downtime; choose dense or sparse shard placement across nodes.	Grow throughput and resilience on demand while maintaining sub-millisecond latency.

Ideal Use Cases

Best for large-scale, multi-tenant platforms: Because shard-based licensing matches the way Redis Software scales—many databases, each with configurable shards and RAM quotas—without forcing “one cluster per team” or per-app licensing.
Best for regulated or controlled environments: Because Redis Software runs on your infrastructure (on‑prem or self-managed clouds) with full control over networking, ACLs, TLS, and failover, while shard-based pricing still keeps cost understandable and predictable.

Limitations & Considerations

You need to think in shards, not just GBs:
While RAM and throughput strongly influence how many shards you need, the license itself is about shard count. Sizing requires a bit of upfront planning with Redis architects to translate capacity and latency targets into a shard number.
High availability and replicas affect effective capacity:
For strong HA, Redis Software typically places master shards and replicas on separate nodes, racks, and zones using in-memory replication. This improves resilience but means your usable data capacity per shard can be lower than raw RAM, since replicas consume memory too. Plan for this in both capacity and budget conversations.

Pricing & Plans

Redis doesn’t publish flat price tables for Redis Enterprise Software because every deployment looks slightly different: hardware, cloud provider, storage (RAM vs RAM+Flash), Active-Active, and compliance requirements all affect cost.

Instead, pricing is typically:

Subscription-based: Annual or multi-year subscription for a licensed number of shards, plus enterprise support.
Shard-count anchored: You estimate initial shard needs (including replicas and growth headroom), then license that number. As you add shards or databases, you can adjust the subscription.
Deployment-agnostic: Whether you run Redis Software on‑prem, in your own AWS/Azure/GCP accounts, or in Kubernetes, the licensing model is still rooted in shards, not vendor-specific instances.

A typical quote process:

Workload discovery:
- How many applications and databases?
- Read/write throughput targets and p99 latency goals?
- Required RAM per dataset, plus growth expectations?
- HA/DR requirements (multi-AZ, multi-region, Active-Active)?
Shard & topology design:
Redis architects help you translate those requirements into:
- Number of shards per database.
- Expected replica configuration for HA.
- Shard placement policy (dense vs sparse) based on performance and resilience targets.
- Node counts and hardware recommendations.
Commercial proposal:
Redis sales produces a shard-based subscription quote that includes:
- Number of licensed shards (and any Flash vs RAM-tiering assumptions).
- Support level and SLAs.
- Any add-ons (e.g., Active-Active Geo Distribution) if needed.

Because details can change with every workload, the only reliable way to get an accurate price is to request a quote directly from Redis.

Standard Plan (illustrative): Best for teams needing a few to dozens of databases with strong HA, sub-millisecond latency, and standard enterprise support.
Scale & Multi-Tenant Plan (illustrative): Best for platform teams needing hundreds of databases and 100s–1000s of shards, with multi-AZ, multi-region, or Active-Active options and higher support commitments.

Note: Naming and structure of plans can change; the key invariant is the shard-based licensing underneath. Your quote will be tailored to your shard count and feature set, not generic “small/medium/large” tiers.

Frequently Asked Questions

How does shard-based licensing in Redis Enterprise Software actually work?

Short Answer: You license Redis Enterprise Software by the number of shards you run in your cluster, sized around your memory, throughput, and HA needs.

Details:
Redis Software is built to scale to hundreds of databases per cluster, where each database can have a configurable number of Redis shards. Shards are the fundamental unit of:

Capacity: Each shard has a share of the database’s RAM quota.
Throughput: Adding shards increases parallelism and read/write capacity.
Resilience: HA is implemented by placing master shards and replicas on separate nodes, racks, and zones, with in-memory replication.

Licensing aligns with this model: instead of counting nodes or per-database fees, you pay for the number of shards participating in your databases. As you reshard databases to scale throughput—Redis Software can reshard into more shards without downtime—you’re effectively increasing the number of licensed shards. That’s why sizing exercises focus on:

Dataset size and growth (to determine RAM per shard).
Throughput and latency targets (to determine shard count).
HA/DR strategy (to determine replica shards and placements).

How do I get an accurate Redis Enterprise Software price quote?

Short Answer: Use Redis’s contact or meeting form, share your workload and deployment details, and request a shard-based Redis Enterprise Software quote.

Details:
Because Redis Enterprise Software is deployed on your own infrastructure (on‑prem, private cloud, Kubernetes), pricing depends on your architecture. To get a precise quote:

Gather key information:
- Estimated total dataset size in memory (now and in 12–36 months).
- Read/write throughput and latency goals (e.g., p95/p99 SLA).
- Number of applications and databases you plan to deploy.
- HA/DR requirements: multi-AZ, multi-region, RPO/RTO targets.
- Preferred deployment model (bare metal/VMs/Kubernetes; AWS/Azure/GCP or on‑prem).
Request a meeting with Redis:
Go to the Redis site and schedule time with the Redis team:
https://redis.io/meeting/
Work through shard sizing with Redis engineers:
They’ll propose:
- A cluster layout (nodes, dense vs sparse shard placement).
- Initial shard counts (masters + replicas) per database.
- Recommended observability setup (Prometheus/Grafana with latency histograms, Redis Insight for debugging).
Review the shard-based subscription proposal:
You’ll receive commercial terms tied directly to those shard counts, plus support and feature options. If your workloads or growth projections change, you can iterate on the design and quote.

Summary

Redis Enterprise Software pricing is built around the same unit that drives performance and scale in the product: shards. Each database in a Redis Software cluster is made up of shards, and you can scale throughput and capacity by adding more shards, resharding online, and adjusting shard placement. Licensing takes advantage of that model by charging per shard rather than per node or per-database, giving you a clean line between what you pay and the capacity you get.

For an accurate cost, you’ll walk through a sizing exercise with Redis to translate your datasets, throughput targets, and HA requirements into a shard count, then receive a shard-based subscription quote.

Next Step

Get Started