SSD Data Tiering is now on Dragonfly Cloud

SSD Data Tiering is now available on Dragonfly Cloud for AWS and GCP. This is something our Dragonfly Cloud customers have been requesting since tiering became Generally Available (GA) on Community Edition. Dragonfly multi-threading architecture broke the limits for higher throughput applications, now SSD tiering breaks the limits for memory-bound workloads. 

SSD Data Tiering expands the total memory capacity up to 8X by offloading values to SSD storage. This reduces the cost by up to 80%. 

It’s now on our managed service, which means you get more memory at lower cost without needing to maintain it yourself.

"With SSD Data Tiering, we can hold far more data in memory at much lower cost, without sacrificing performance. We started with SSD Data Tiering in Dragonfly's Community Edition and moved to their Dragonfly Cloud service for the support and the ease of operations. The team behind it has been excellent throughout." - Yash Shah, SDE@ Meesho

SSD Data Tiering dynamically moves less-used data off RAM to SSD

Dragonfly’s SSD Data Tiering feature allows it to store data on SSD drives, extending the potential size of a workload up to 8X times more than there is RAM available. Hot values  remain in RAM to keep latency low, while Dragonfly's asynchronous nature allows it to saturate the SSD drive and maintain high throughputs. Most importantly, this feature works transparently and does not require any application code changes.

15X better than SSD data tiering in ElastiCache for reads

In June 2026, we benchmarked Dragonfly Cloud data tiering against Amazon ElastiCache data tiering, the closest managed comparison, on matched local-SSD hardware. Dragonfly consistently performed 15X better across throughput, latency, and p99 latency for reads, and >2X better for writes.

Write phase

Read Access Phase (100% GET, Gaussian σ=2%, 600 s)

The gap traces directly back to the architecture. ElastiCache data tiering can't serve a read from SSD. It has to promote the value back into RAM first, blocking the client while a small background thread pool works through those promotions one queue deep, so reads stall long before the drive is saturated.. Dragonfly reads the value straight off SSD in a single asynchronous io_uring operation, issued in parallel across every core, so the drive runs at its full IOPS ceiling.

Meesho gets 20% lower latency & 70% cost savings for 300GB workload

Meesho, one of India's largest e-commerce platforms, sells everything from bedsheets to Bluetooth earbuds to hundreds of millions of value-conscious shoppers, serving 175 million annual transacting users. One of their P0 caches was memory-bound: a 300GB working set against 45GB of RAM capacity, running at roughly 30K ops/sec. Running it as a pure in-memory store meant paying for a large memory footprint while CPU sat underutilized.

Long standing customer Meesho found that by moving to SSD Data Tiering, they have measured 20 to 25% lower latency at equivalent load, alongside roughly 70% cost savings for the same cache workload. 

"Setup was genuinely straightforward. No complex flags, no fiddly configuration. Dragonfly delivered on both performance and economics without the operational tax we expected." - Yash Shah, SDE at Meesho

Pricing: 8X of the memory. 20% of the cost.

SSD Data Tiering modifies how you buy capacity and what you get. You provision RAM in Dragonfly Cloud and get tiered memory: RAM plus local NVMe, working as one pool. Dragonfly keeps hot data in RAM and offloads cold values to SSD.

The rate for tiered-memory is 1.5X the standard RAM rate. The $11/GB/month becomes $16.5/GB/month. The SSD memory is included. For that you get 8X the capacity. The SSD is not a separate line item.

Validate the math against your own workload in your Dragonfly Cloud account.

Example: a 400GB dataset with 50GB hot.

Tiering is on Flex ($36/month and up) and Business ($2,000/month and up) for Enhanced (2X Compute) and Extreme (4X Compute) data stores.

SSD Data Tiering is ideal for memory-bound workloads

Data tiering works best for workloads that are memory-bound rather than compute-bound, where dataset size is the primary constraint and a meaningful fraction of the data is not hot.

Examples include:

• ML feature stores: Inference datasets routinely hit dozens of GB with a small active slice. That trade buys multiples of capacity, which is usually the right side of the deal for a feature store.
• Job queues: A single list holds all pending jobs. Workers read one end, producers append the other, and the middle sits untouched, which is exactly what list tiering offloads.
• Read-mostly reference caches: Product catalogs, rendered content and API responses are large string values, read constantly and rewritten rarely, so most of the set can sit on NVMe.

If you are on ElastiCache or Memorystore and have added nodes purely to add memory, SSD data tiering is for you. 

We’re always adding more. Need something? Talk to our team.

Full support today in Dragonfly Cloud covers string values (those over 64 bytes by default; the threshold is configurable). Support for lists and small hashes will follow soon. 

Get started today

Tiering is a provisioning option on new and existing Dragonfly Cloud datastores on AWS and GCP. We handle the local-SSD instance selection, the offload and upload thresholds, and the tiering metrics in your dashboard.

• Start a free trial: https://dragonflydb.cloud/signup
• Get a sizing review: https://www.dragonflydb.io/speak-to-sales
• Read the docs: https://www.dragonflydb.io/docs/managing-dragonfly/tiering
• Watch the Getting Started Video: https://youtu.be/sF2DKvFpTMk

Running tiering in Community Edition already and thinking about handing off the operations? That is the shortest migration we do, and the tuning moves to the people who wrote the storage engine.