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

Redis Enterprise Software (often just called Redis Software) doesn’t use the usual “per-core” or “per-server” pricing model. Instead, it’s licensed primarily by shards—the building blocks that power your databases’ throughput and availability. Understanding shard-based licensing is key to estimating costs and planning capacity, and it also helps you ask the right questions when you request a quote.

Quick Answer: Redis Enterprise Software (Redis Software) pricing is typically based on the number of Redis shards you license, plus support and add-ons. You estimate shards from your memory footprint, throughput, and availability requirements, then work with Redis to size your cluster and get a tailored quote.

The Quick Overview

What It Is: A shard-based licensing model for Redis Software, where you license a pool of Redis shards that can be allocated across many databases and tenants.
Who It Is For: Platform and infrastructure teams running Redis on their own infrastructure (on‑prem, VMs, or Kubernetes) who need predictable pricing, strict SLAs, and fine-grained control over performance and multi‑tenancy.
Core Problem Solved: Traditional per-VM or per-core pricing doesn’t align well with how Redis actually scales. Shard-based licensing ties cost directly to the resources that matter for latency, throughput, and resilience.

How It Works

Redis Software is built around clusters, databases, and shards:

A cluster: a set of nodes running Redis Software, managed as a single control plane.
A database: a logical Redis deployment (or tenant) inside that cluster.
A shard: the fundamental unit of compute and memory that holds a subset of keys and serves traffic.

Pricing is driven by how many shards you license for the cluster. You can then:

Create hundreds of databases per cluster for different apps, teams, or tenants.
Assign one shard or many shards to each database, depending on throughput and capacity needs.
Reshard databases online as load grows—without downtime—by rolling data into more shards.

Shard-based licensing focuses on the resources that actually drive performance:

Capacity & Throughput Sizing:
- Estimate your RAM footprint (and Flash, if you’re using tiered storage).
- Estimate operations per second and desired tail latencies (p99/p99.9).
- Convert those targets into the number and size of shards required.
High Availability & Replication:
- Redis Software places master shards and replicas on separate nodes, racks, and zones, and uses in-memory replication for resilience.
- Each master shard typically comes with at least one replica shard; both master and replicas count in the shard pool that drives licensing.
Multi‑Tenancy & Growth:
- You can scale to hundreds of databases per cluster and allocate your shard pool among them.
- As workloads grow, you reshard databases into more shards to scale throughput while maintaining sub‑millisecond latency—again, this directly relates to how many licensed shards you need.

In practice, Redis will walk you through sizing based on your current footprint and growth expectations, then translate that into a shard-based quote.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Shard-based licensing	Prices Redis Software based on the number of Redis shards in your cluster.	Aligns cost with performance and capacity, not VM count.
Online resharding	Reshard databases into more Redis shards with no downtime.	Scale throughput on demand without maintenance windows.
Flexible multi‑tenancy	Scale to hundreds of databases per cluster, each with its own shards.	Serve many apps/teams from one cluster with clear isolation.
HA shard placement	Puts master shards and replicas on separate nodes/racks/zones.	Higher resilience and automatic failover if a node fails.
Shard placement policies	Choose dense (pack shards) or sparse (spread shards) per cluster.	Optimize for cost vs. availability and failure domains.
Cluster metrics & UI	Monitor clusters, nodes, databases, and shards in real-time via UI & APIs.	Visibility into shard utilization, latency, and capacity.

How a “Shard” Maps to Your Workloads

Because licensing is shard-based, it’s worth being concrete about how shards behave in Redis Software.

1. Shards inside databases

Each database in Redis Software:

Can contain one or many Redis shards.
Has its own RAM quota; the quota can’t exceed the RAM of the node hosting its shards.
Can be resharded into more shards to scale throughput while maintaining sub‑millisecond latency.

Sharding is transparent to Redis applications: your client talks to the database endpoint, and Redis Software handles routing requests to the correct shard based on key. Your team doesn’t have to manually partition keys or manage shard topology.

2. Shards inside clusters

A Redis Software cluster:

Can scale to hundreds of databases, each mapped to one or more shards.
Places shards on cluster nodes according to a shard placement policy:
- dense: pack as many shards as possible on the smallest number of nodes (cost‑efficient).
- sparse: spread shards across many nodes (better fault isolation and resilience).

These policies don’t change how shards are licensed, but they shape how you deploy nodes and how many nodes you’ll need to host a given shard pool.

How Shard-Based Licensing Affects Planning

When you think about pricing for Redis Enterprise Software, you’re really thinking about how many shards you need today and how many you’ll grow into.

1. Start from memory and throughput

Typical discovery questions:

How much hot data lives in memory today?
- By service: user sessions, queues, ephemeral state.
- By AI workloads: vector embeddings, JSON documents, semantic cache entries.
What’s your current and target ops/sec per workload?
What are your latency SLOs, especially p95/p99 under peak load?
Are you planning to use tiered storage (RAM + Flash) to reduce RAM cost?

Redis will convert these into:

Shard size (e.g., X GB per shard).
Shards per database needed to meet throughput and latency goals.
Replica shards to meet HA requirements (often 1:1 with master shards).

The total of (masters + replicas) is the core input to shard-based pricing.

2. Factor in HA and disaster recovery

If you need:

Automatic failover within a cluster and
Multi-zone or multi‑rack resilience

…then your architecture will use replicas and spread shards across nodes, racks, or zones. This increases the number of shards (and thus license count), but it also protects your uptime.

For stricter RTO/RPO targets or cross‑region deployments, you may also layer:

Active‑Active or other replication topologies across clusters.
Additional clusters in different data centers or clouds.

Each participating cluster’s shard capacity contributes to licensing; this is where a detailed sizing call with Redis becomes essential.

3. Plan for multi‑tenancy

Redis Software is designed to scale to hundreds of databases per cluster. Shard-based licensing makes it easier to:

Run many apps or tenants on one cluster.
Start each database small (1 shard) and grow shard count as each tenant or service scales.
Use different shard placement policies by cluster to balance cost and resilience.

From a pricing perspective, you’re paying for a shared shard pool that all those databases consume, not for each database individually.

Ideal Use Cases

Best for large, multi‑tenant platforms: Because shard-based licensing matches how platforms segment workloads—by databases and shards—across shared clusters. You can give each product, team, or tenant their own logical database while keeping a central shard pool.
Best for regulated or on‑prem environments: Because Redis Software runs on your own infrastructure (on‑prem, private cloud, Kubernetes, or VMs). Shard-based pricing lets you scale capacity locally without being bound to a specific VM shape or cloud SKU.

Limitations & Considerations

No public price list for shards:
Redis doesn’t publish $/shard pricing for Redis Software. You’ll need to walk through sizing with Redis sales to get an actual number.
Workaround: Come prepared with memory, throughput, and HA requirements so you can get to a concrete quote faster.
Replica and DR shards still count:
Every shard (master or replica) consumes part of your licensed shard pool. If you want aggressive HA, multi‑zone, or DR topologies, your shard count—and thus your license requirement—will increase.
Note: This is usually a good trade: you’re paying more shards for higher guaranteed uptime and lower operational risk.
Node‑level constraints still apply:
Each database has a RAM quota that cannot exceed the RAM available on its node. Even with many licensed shards, you still need appropriate node sizing and placement to meet performance targets.

How to Get a Redis Enterprise Software Pricing Quote

Redis Software (Redis Enterprise Software) is sold directly by Redis and via some partners; you won’t find an automated “swipe your card” calculator on redis.io for shard-based licensing. Here’s how to approach getting a quote that doesn’t waste your time.

1. Gather your sizing inputs

Before you talk to Redis, it helps to have:

Current Redis footprint
- Total memory in use (GB/TB) for existing Redis or caches.
- Any Flash/tiered storage you plan to use.
Traffic profile
- Peak ops/sec (reads and writes).
- Latency targets (p95/p99), especially for critical APIs.
Topologies & constraints
- Desired HA model (single region, multi‑AZ, multi‑region).
- Number of environments (prod, staging, dev) to run as separate clusters.
- Regulatory or residency constraints (specific data centers, clouds).
Growth expectations
- Projected data growth over 12–36 months.
- Expected increase in tenants, customers, or AI workloads.

With these, Redis can quickly translate into shard counts, node counts, and pricing.

2. Contact Redis for a shard-based quote

To start the quote process:

Visit the Redis site’s contact or sales pages from redis.io.
Or use the consultation link the team typically shares for Redis Software discussions:

Get Started

This will connect you with Redis specialists who:

Propose an architecture (clusters, shards, HA topology).
Estimate the number of shards required for your initial deployment and growth.
Provide pricing based on:
- Shard count and tier.
- Support level and SLAs.
- Any advanced features or add‑ons you need.

3. Ask the right pricing questions

When you’re on the call, it’s worth asking:

How does master vs. replica shard count affect my license?
How does pricing change if I add more databases per cluster?
What’s the recommended shard size and max memory per shard for my workloads?
How do Active‑Active or DR patterns influence shard count and cost?
How does pricing scale as I reshard databases to handle higher throughput?

This ensures the quote you receive maps directly to how you plan to operate Redis in production.

Frequently Asked Questions

How does Redis Enterprise Software shard-based licensing compare to Redis Cloud pricing?

Short Answer: Redis Software uses shard‑based licensing on your own infrastructure, while Redis Cloud is a consumption-based, fully managed service billed by memory usage and throughput in the public cloud.

Details:
Redis Cloud is a SaaS offer—you pay by the GB and capacity you consume, typically billed hourly with fine-grained metering. It’s ideal if you don’t want to manage infrastructure.
Redis Software is the self-managed option designed for on‑prem and hybrid deployments. Pricing is built around licensed shards, running on your hardware or IaaS, with enterprise support layered on top. You get more control over placement (nodes, racks, zones), multi‑tenancy, and integration with your own observability and security stack.

Can I change my shard count after I purchase Redis Enterprise Software?

Short Answer: Yes. You can add more shards and reshard databases over time, but contract and pricing updates will be handled through Redis.

Details:
Operationally, Redis Software lets you:

Reshard databases without downtime to increase throughput.
Add more databases and allocate shards as new workloads come online.
Adjust shard placement policies (dense vs. sparse) as your resilience and cost priorities evolve.

Commercially, if you outgrow your existing shard license pool, you’ll work with Redis to expand your license. It’s common to start with a shard count sized for 12–18 months of growth, then renegotiate as your footprint and business needs evolve.

Summary

Redis Enterprise Software pricing is built around shard-based licensing: you license a pool of Redis shards that power all your databases and workloads inside a cluster. This model maps directly to how Redis scales—via more shards for more throughput, capacity, and availability—so cost stays aligned with the actual performance characteristics your apps depend on.

Each database can use one or many shards, can be re‑sharded online, and can participate in HA and DR topologies. Master and replica shards both count towards your licensed capacity, and shard placement policies (dense or sparse) determine how those shards sit on your nodes and fault domains.

Because shard pricing isn’t published, the practical path to a number is simple: bring your memory, throughput, and HA requirements to Redis, let them translate that into shard counts and architecture, and use that to get an accurate quote.

Next Step

Ready to talk specifics for your environment, shard counts, and SLA needs?
Get Started