Comparing Low-Latency Databases: Aerospike and ScyllaDB

Comparing Low-Latency Databases: Aerospike and ScyllaDB

• 1.
  Comparing Low-Latency Databases: Aerospikeand ScyllaDB August 27, 2026 | 10am PT | 1pm ET | 6pm BST The webinar will begin shortly…
• 2.
  Felipe Mendes, TechnicalDirector at ScyllaDB Guilherme Nogueira, Technical Director at ScyllaDB Comparing Low-Latency Databases Aerospike and ScyllaDB
• 3.
  Introductions Felipe Mendes, TechnicalDirector at ScyllaDB + Published Author on Linux and Databases + Helps teams solve their most challenging problems + Years of experience with Linux and distributed systems Guilherme Nogueira, Technical Director at ScyllaDB + Previously Solutions Architect + Publishing + Streaming + Automotive
• 4.
  Agenda ScyllaDB andAerospike Fundamentals Supported Data Models & Querying Flexibility Consistency & Durability Tradeoffs Day 2 Operations Storage Engine Internals Takeaways 4
• 5.
  Beyond the Benchmark 5
• 6.
  A recent benchmarkclaimed Aerospike as the winner. A 3rd party vendor ran the benchmark and reported the numbers. But the workload primarily focused on the key-value access pattern Aerospike is optimized for. In this webinar, we’ll: ● Compare the DBs beyond just performance numbers ● Why these databases fundamentally differ architecturally ● What performance tests don't show ● Costs of architectural flexibility (or the lack thereof) The Controversy 6
• 7.
  Comparing ScyllaDB and Aerospike Fundamentaldifferences between high performance databases 7
• 8.
  8 + Key-value /record-oriented + Keys (indexes) entirely in RAM + Data (values) on fast NVMe/SSD + Other modes available + Custom storage engine + direct block-device I/O High level architecture + Wide-column + Shard-per-core, linear scalability + Leverage super dense nodes + Storage: 100’s of TB/node + Memory: Multiple TB/node + >256 vCPUs + Cassandra (CQL) and DynamoDB API compatibility Aerospike ScyllaDB
• 9.
  9 A collection ofrecords, each with a key and its value (bins) + Highly optimized for simple K/V lookup + Caches primary keys in RAM + Values reside on fast NVMe storage + Optimized for throughput on basic operations Architectural foundations A key-key-value architecture supporting millions of independent cells + Partition Key: Identifies the partition + Clustering Keys: Order rows within the partition + High design flexibility + Caches Index pages and Rows in memory Aerospike: Key-Value (KV) ScyllaDB: Wide-Column (KKV)
• 10.
  10 + Namespace =database + Set = table + Bin = column/attribute + Schemaless records + Keys are enforced + SI + Collections: Lists, Maps Schema design + Keyspaces + Tables + Primary key = partition key + optional clustering columns + Columns + All columns are enforced + And their type + MV / SI + Collections: Sets, Lists, Maps + Vector embeddings for AI use-cases Aerospike: Key-Value (KV) ScyllaDB: Wide-Column (KKV)
• 11.
  11 + RAM-Pinned Keys +64 bytes per key (metadata) + Record count as a sizing constraint + RAM overhead + Especially tiny records Memory architecture + RAM as LRU Cache + Indexes live on NVMe storage + It caches: + Indexes pages + Data Rows + More by the end of this presentation Aerospike ScyllaDB
• 12.
  12 https://developers.scylladb.com/stable/compare/aerospike.html
• 13.
  13 https://developers.scylladb.com/stable/compare/aerospike.html
• 14.
  14 https://developers.scylladb.com/stable/compare/aerospike.html
• 15.
  Data modeling flexibility Samelow-latency goal. Different data-modeling constraints. 15
• 16.
  16 + KV restrictsdata to a single row + Record, in Aerospike terms + Supports multiple keys combined into a single field (“value1:value2…” etc) + Collections can be used to add depth to a Record + Not a good choice if you need: + Complex modeling scenarios + High-performance ranged queries + A good use-case: + “Give me the profile for user `foo`” + Key: “foo” + Bins: {“type”: “customer”, “location”: “US_West”, “last_seen”: “YYYYMMDD”} KV aspects
• 17.
  17 + Groups rowswithin a single partition + Clustering Keys defines the sorting order + Allows fetching: + Clustering, + IN (...) clauses + Range scans + A natural use-case fit: + “Give me the temperature readings for device = `bar` between Sunday and Wednesday” + SELECT temperature FROM … WHERE device = ‘bar’ AND date > “2026-08-23” AND date < “2026-08-26” + Result: Contiguous range scan over the requested time interval Wide-column (KKV) aspects
• 18.
  18 Power of datamodeling Time-Series & IoT Partition by sensor ID, cluster by timestamp. Fetching precise date ranges becomes a highly efficient, native range scan. Messaging Apps Chronological order is builtin. Append-only event logs process natively without relying on heavy secondary indexes. Leaderboards Clustering order can represent ranking directly within a partition. Sort scores or fetch a whole partition effortlessly.
• 19.
  19 Power of datamodeling Feature Stores Partition by entity, cluster by feature. Allows fetching precise feature values, or a whole partition scan. Ad bidding Partition by targeting attributes. Cluster by bid value in descending order. Precisely fetch a page of the highest bids on that category. Real-time AI Combine superfast Vector Search capabilities with extended features retrieval to power AI pipelines.
• 20.
  TCO Efficiency 20
• 21.
  21 Aerospike ● Narrow primaryaccess model ● Constrained data layouts ● Optimized for known-key access ● Applications: ○ derives keys ○ leverages read batches Flexibility ScyllaDB ● Expressive data modeling ● Partition and clustering-key design ● More query patterns supported ● Performance requires careful modeling
• 22.
  22 Index metadata consumes64 bytes per key ● 1KB record ○ 1:16 RAM:Disk ratio ○ 1TB of data (1 Billion Records @ 1KB) ○ 64GB memory (per replica) ● 256B record ○ 1:4 RAM:Disk ratio ○ 1TB of data (3.9 Billion records @ 256 bytes) ○ 250GB memory (per replica) Index-on-RAM challenge 64 bytes per key
• 23.
  23 Hardware density
• 24.
  Storage Engine Internals Balancingcosts, performance and operations 24
• 25.
  25 Aerospike supported storagemodes: + In-memory, index and data in DRAM ■ Expensive! + Hybrid Memory Architecture ■ Each key holds 64 bytes for hash digest and metadata ■ Infrastructure grows with keyCount + 500M keys → 32GB, 1Bi keys → 64GB, before replication + What happens when memory gets close to full utilization? ■ You can't write anymore + All Flash Mode ■ The slowest performing option ■ Surely not the one you'll see in benchmarks Aerospike – Storage Modes Source: Aerospike
• 26.
  26 + From Aerospike'sdocumentation: ■ New record versions are always copy-on-write persisted + In practice: ■ Writes to new keys amplify memory usage ■ Writes to existing keys incur an extra read + Therefore: ■ Aerospike weakness fall under heavy write load Aerospike – Writing Data
• 27.
  27 Aerospike – Replicationtopology + Aerospike follows a leader-based replication architecture ■ RF=2 is therefore recommended to minimize write amplification ■ A partition gets assigned a primary and a replica, achieving high availability + The problem is that scaling writes become impeditive ■ Which is why Aerospike published benchmarks run at relatively low write rates + On the contrary, read throughput is maximized ■ Every read is node local, requiring zero network coordination ■ … but risks stale reads under the default AP mode + On the contrary, SC mode further sacrifices write performance due to linearizability Source: Aerospike
• 28.
  28 Aerospike – FailureHandling + From Aerospike's documentation: ■ (...) in a 10-node cluster with two copies of the data, if two nodes are simultaneously lost, the amount of unavailable data before replication is approximately 2% or 1/50th of the data + However: ■ Losing a node still requires rebalancing roughly of the cluster's data ■ Consider 1 Billion keys after replication and 4 replicas: + Each replica holds ~32 GB RAM worth of keys ■ After a single node failure: + Default: each of the remaining 3 replicas become responsible for ~10.67GB data + With Rack awareness: only same-rack replica absorb the ~32GB redistribution + Effectively, Aerospike's HMA assumes some free memory quota for uninterruptible operations
• 29.
  29 Aerospike – Scaling +Aerospike can take a very long time to scale ■ This naturally includes migrations as a result of failures + From their own Cassandra published benchmark: ■ At 100K ops/s, redistribution took approximately 6.5 hours ■ At 50K ops/s, redistribution completed in ~3 hours + Works fine for coordinated failures ■ But what about uncoordinated ones? Source: Throughput during failure and recovery – Aerospike
• 30.
  30 ScyllaDB supports twodistinct storage engines: + Standard LSM (the default) ■ Hot reads: Served immediately from ScyllaDB's Cache! ■ Cold reads go through Bloom Filter → Trie Index → Data (and potentially other LSM tiers before merging) before serving live data + K/V Store ■ An in-memory hash table pointing to storage ■ Similar trade-offs as Aerospike's HMA + Every key consumes a few bytes of memory + Memory consumption grows along with the number of keys + Zero read amplification ScyllaDB – Storage Modes LSM write path (WAL is omitted for simplicity)
• 31.
  31 Partial overwrites workby default + Prevents the need for a copy on write ■ Last Write Wins is used for conflict resolution ■ Coming soon: Strong Consistent Tables w/ Raft ScyllaDB – Writing Data
• 32.
  32 ScyllaDB – Replicationtopology + ScyllaDB implements a leaderless replication architecture ■ Every node actively writes and reads from ANY partition (key) in the cluster ■ RF=3 is a recommendation, rather than an enforcement + The problem is ensuring consistent reads ■ In contrast with Aerospike's leader-follower design, reading your own writes DO require a network round trip under RF=3 + The solution for RF=2? ■ Write with Quorum (or ALL) ■ Read with One ■ Very same guarantees as Aerospike promises
• 33.
  33 ScyllaDB – FailureHandling + With RF=3 and Quorum requests, the cluster remains available even under a whole AZ failure ■ Available means other AZs will observe higher traffic during since you'll be one AZ short in replicas ■ But other than that, no "rebalancing" will take place until the operator replaces the failed nodes ■ So long the cluster is correctly sized to tolerate a full AZ loss (+33% traffic), performance should go unaffected + With RF=2 and Quorum Writes, the application must implement its own failover semantics: ■ Technically speaking, the loss of a single node is already an invitation for data loss + Hence why we recommend RF=3 ■ Still, applications may dynamically downgrade their write consistency requirements via DowngradingConsistencyRetryPolicy ■ Or stop accepting writes until the situation is corrected + Notice there is no "right" or "wrong" here. Unlike Aerospike, ScyllaDB will defers decision to YOU.
• 34.
  34 ScyllaDB – Scaling +Tablets enable fast scaling within minutes for ScyllaDB ■ Bootstrap and decommission nodes in parallel ■ Dynamic data distribution and topology-aware balancing ■ Replace multiple replicas at once, fast. RF = 2
• 35.
  35 ScyllaDB – HeterogeneousDeployments ■ Fewer tablets on smaller instances ■ Cost-effective scale-out ■ Weighted traffic ■ Topology aware node A node B
• 36.
  36 ScyllaDB – EnablingK/V Mode CREATE TABLE keyspace.user_profiles ( user_id uuid PRIMARY KEY, name text, email text, metadata frozen<map<text, text>> ) WITH storage_engine = 'logstor'; Subject to change
• 37.
  37 + Standard LSM(the default) ■ Use when: + Use case benefits from clustering keys and range queries ○ SELECT … FROM tbl WHERE key = ? AND ts >= ? AND ts < ? + Payload size is too small (<2KB) to justify per-item RAM overhead + Working set is dense (RAM:disk ratio) + Majority of reads are frequently accessed data, and P99 reads are good enough + K/V Store ■ Use when: + The lowest possible tail latency for reads is needed + Workload is genuinely a simple K/V with point lookups + Reads dominates and keyCount is relatively bound ScyllaDB – When to use what? Early K/V Store results (Uniform i4i.4xlarge – 4 instances, 480K ops/sec)
• 38.
  True Elastic Scaling
• 39.
  90% Storage Utilization
• 40.
  Takeaways + ScyllaDB andAerospike optimize for low latencies in different ways ■ Aerospike's HMA poses a hard scalability ceiling, affecting TCO at scale + Primarily optimized for read-intensive traffic + TCO promises assume a bound working set size + Data model is relatively inflexible, but a good fit for traditional K/Vs + Proprietary API limits ecosystem integrations and eventual migration out ■ ScyllaDB defaults to fully maximizing every hardware aspect + Default LSM provides a fine balance for the majority of workloads + K/V mode enables gives users a choice for further infrastructure consolidation + Natively supports a wider range of use cases, fully compatible with industry APIs + Easier and faster maintenance and operations are a plus! + When benchmarking, compare apples to apples ■ If you use RF=2 on Aerospike, surely do the same for ScyllaDB (and vice versa) ■ Stress the system under failure and an increasingly working set (writes) ■ Most importantly, test your very own workload. We are here to help!
• 41.
  All Things Performance AScyllaDB Community Virtual Event | OCTOBER 21 + 22, 2026 Register now at p99conf.io
• 42.
  Nowogrodzka 21 00-511 Warszawa,Poland United States 1309 S Mary Ave Suite 219 Sunnyvale, CA 94087 USA Israel Maskit 4 Herzliya, Israel 4673304 www.scylladb.com @scylladb Poland Thank You!