Flexibility doesn’t have to come at the expense of performance. ScyllaDB beats Aerospike performance for key-value workloads. And when you need to go beyond K/V, ScyllaDB supports complex data models, vector search, and elastic scaling for dynamic workloads. You won’t be fighting your database every time your data grows or your workloads evolve.
Every new use case shouldn’t require a new database. Simple sets and bins aren’t sufficient as applications require more sophisticated access patterns (e.g., for time series data, AI retrieval, personalization, fraud detection…). ScyllaDB supports KV, Key-Key-Value, and vector embeddings, all on one database built for mutli-region global scale.
ScyllaDB scales capacity in just minutes so you don’t need to overprovision. You can scale from 500K OPS to 2M in ~10 minutes. This is ideal for dynamic and rapidly-growing that would become costly on Aerospike. ScyllaDB can run at 90% storage utilization, yielding additional cost savings. And we don’t force you to store primary indexes in RAM.
Don’t be a beta tester. ScyllaDB’s fully-managed DBaaS has been running data-intensive production workloads since 2019. Leading teams (e.g., Tripadvisor, Freshworks, and Supercell) let ScyllaDB experts manage their database so they can focus on building their applications. It’s highly resilient and battle-tested at massive global scale.
ScyllaDB and Aerospike are both fast, but their architectures are fundamentally different.
Aerospike is a very good key/value database. Caching keys in RAM while values live on fast NVMe is a novel approach for a simple K/V model. It achieves excellent throughput and superb low latency.
ScyllaDB is a more sophisticated database: wide-column NoSQL, a strict superset of K/V, with millions of independent cells per row, configurable replication, local and global indexes, and true elasticity.
Aerospike follows a Key-Value approach to data modeling. It organizes data into Namespaces (databases), Sets (tables) and Records (rows). Inside a record, data is stored in Bins (similar to columns in other DBs). It favors single-record lookups (for example, fetching a user profile by its ID) and when more complex data storage is needed it operates similarly to a Document database by aggregating multiple datapoints into a single Record (row).
ScyllaDB’s approach is called Wide-Column, a highly structured tabular model. Data is organized into Keyspaces (databases), Tables and Rows, with Columns to store various data types. Its main Data distribution mode is driven by Partitions. A Partition Key is a Primary Key (or a group thereof) which determines which nodes hold the data. A Clustering Key (or a group…) defines the sorting of rows in the context of a partition.
ScyllaDB’s model supports a significantly richer set of Applications that requires querying relationships or fetching blocks of related data.
Aerospike’s fundamental Key-Value design isn’t designed to facilitate fetching a series of related data points. In its design, you either have to rely heavily on Secondary Indexes (which comes with memory/performance overhead) or abuse Collections Data Types (CDTs) like Maps and Lists within a single bin. However, overloading a single record with massive lists can lead to bloated records and create performance bottlenecks.
ScyllaDB’s Clustering Keys natively sort data on disk. As you partition your data by `sensor_id`and cluster it by `timestamp`, you can easily query, for example, “fetch all temperature sensor readings for Sensor A between Tuesday and Friday”. ScyllaDB serves this query via a highly efficient sequential read directly from disk/memory and returns the requested pieces of data. This makes ScyllaDB exceptionally powerful for time-series data, such as event logging, messaging systems and IoT workloads.
Aerospike does not enforce a schema except for its Primary Key. You can write a record with a `user_name` bin as a string, and in the next record, write `user_name` as an integer. This flexibility feels liberating as you get started, but at an Enterprise scale with applications spanning multiple years of development and Production maintenance, this shifts the burden of data validation and schema governance onto the application code. Over time, this creates a multitude of setups where data types are inconsistent and bugs are difficult to track down.
ScyllaDB does enforce a schema under CQL. This guarantees data integrity and predictable data types at the database level. It allows for some dynamicity – you can `ALTER TABLE` to add new columns or collections on the fly without locking the database or experiencing downtime.
Under the DynamoDB-compatible API, ScyllaDB follows the DynamoDB data modeling, which has Primary Key and an optional Sorting Key, with no restrictions on the Item attributes.
Often, applications need to query the exact same data from two different perspectives. For example, query a user by `user_id“ or by `email_address`.
Aerospike offers Secondary Indexes, which structurally function as Local Secondary Indexes (LSIs) rather than Global Indexes. Each node maintains a local, in-memory version of the indexed bin with a reference to the original record. When querying using Secondary Indexes, clients are unaware of which nodes hold the corresponding data, so clients perform a scatter-gather operation which broadcasts the query to all nodes to check for partitions. The partitions are then aggregated on each node and flushed onto the network. This is a highly compute-intensive operation, which drives some users requiring strict latency SLAs to be met to use a dual-write system, writing in parallel to two tables with the corresponding desired Keys, shifting the burden of keeping data between base table and Secondary Index to the application.
ScyllaDB supports three types of data views: both Local and Global Secondary Indexes, and Materialized Views.
Aerospike relies heavily on Collection Data Types (CDTs), especially Lists and Maps. These data types allow for recursive, document-like manipulation of nested data within a Bin.
ScyllaDB supports regular collections (Sets, Lists, Maps) but also offers User-Defined Types (UDTs). A UDT allows you to define a custom, complex data structure (for example, an `address` containing `street`, `city`, `zip`) and use it as a standard column type across multiple tables. This approach favors reusability and clean data modeling.
Aerospike copy-on-write storage mechanism, while optimized for direct disk access, creates bottlenecks during heavy write or update workloads. As old data blocks are marked as stale, the system must trigger aggressive background garbage collection (defragmentation) processes to consolidate data and reclaim disk space. This results in constant reading, rewriting and flushing, which manifests as high write amplification and CPU overhead. Under resource contention, performance might be affected and latencies spike. Administrators usually throttle Defragmentation to reduce its performance impact.
ScyllaDB’s Log-Structured Merge Tree storage mode flushes data to immutable disk files called SSTables. As writes, especially updates to existing data, are flushed onto disk, it generates a new SSTable file. A background task called compaction is responsible for merging these disk files, creating new ones and deleting the ones it compacted away. This process is done in the background, and ScyllaDB’s internal I/O schedulers ensure it doesn’t impact user workloads.
Aerospike splits the dataset into 4096 partitions, which are distributed across the cluster. When a cluster scales, these partitions are sent over the network to other nodes in a process called Migrations. Although Migrations are background tasks by definition, they still can cause performance problems and latency spikes, due to their massive Disk and Network I/O usage. Administrators are recommended to throttle Migrations speed in a factor that allows their application to continue to serve traffic while not massively extending the time to complete the operation.
ScyllaDB’s efficiency stems from its close to the hardware, shard-per-core design. In it, each CPU core is a self-contained unit that owns a piece of the dataset. There is no locking or contention between shards, they all have dedicated RAM and I/O access for processing.
Tablets are used as a data split mechanism, with each tablet containing a given amount of partitions depending on the dataset size and cluster size. As the cluster grows or shrinks, tablets are efficiently sent over the network between nodes, reducing the overall time to scale.
Aerospike stores indexes of all partitions on a given cluster in memory by default. It optionally can store indexes on disk, in what is called All Flash mode, although at the cost of higher read latency. Records (rows) are read from disk.
Effectively, memory is the primary resource to be monitored on Aerospike clusters. Each Index entry is represented as a 64 bytes item. As data is written, the number of entries in memory grows. If a node reaches 90% (default setting, configurable) memory utilization it enters `stop-writes` mode, in which writes to the cluster are interrupted until the issue is addressed.
ScyllaDB utilizes system memory mostly for cache. It caches both indexes and rows, using LRU (Least Recently Used) to purge older entries to make room for fresh data. ScyllaDB does not force memory to be utilized for indexes or data, it efficiently makes the most out of it by intelligently managing entries as needed.
Due to its fixed bytes-per-row Index overhead, billion-row scale workloads are more cost-efficient in ScyllaDB than Aerospike.
Aerospike relies on OS-native threads, pooled by task type (such as transaction, partition balance, network, etc). By relying on native OS threads, Aerospike relinquishes control over thread scheduling, which makes it more subject to scheduling and context switching than ScyllaDB. Vertically scaling requires tuning thread pools to prevent OS scheduling overhead.
ScyllaDB is designed to run at 90%+ CPU utilization. This CPU utilization maximization is due to ScyllaDB’s internal Workload Prioritization, which pushes internal tasks to the background while user operations take full priority on the system.
Workload Prioritization also allows ScyllaDB to run OLAP workloads alongside latency-sensitive OLTP workloads without impacting OLTP performance and latency.
Aerospike uses a proprietary, opaque storage format that directly accesses a device to persist data, bypassing filesystems. This means any operations, such as backups, have to rely on Aerospike products to access the data. Disk utilization is set to up to 90% by default, but usually tuned to a much lower value for write-intensive, append-mostly workloads.
ScyllaDB recommends industry-standard, battle-tested XFS for its data filesystems. Flash devices are recommended for high throughput, low latency access. The filesystem stores all ScyllaDB data assets, such as SSTable files and indexes and commitlog files.
ScyllaDB maximizes disk utilization, allowing users to maximize disk space utilization (90% on ScyllaDB X Cloud) without risking availability.
Aerospike relies on storing indexes in RAM and data on flash. This architecture is aimed at speed, but might hurt when running at scale. As data grows, RAM requirements for Indexes grow proportionally. At some point, storing all rows’ index entries in memory might not be the priority.
ScyllaDB, built on top of Seastar, leverages its shard-per-core, shared-nothing design to remove any global lock contentions. It allows ScyllaDB to efficiently scale to multi-core (256+ vCPUs) instances while providing linear scalability due to its lockless design.
Aerospike supports Global replication via Cross-Datacenter Replication (XDR) and Multi-Site Clustering, which the latter is a paid add-on. Multi-Site Clustering is recommended for active-active deployments where conflicting writes might come from any Region, but it has increased latency as every Region must commit the write before it succeeds.
ScyllaDB’s design allows for native Global replication, with eventually-consistent active-active replication between regions. Reads and writes are served locally, and eventually-consistent replication happens without affecting the user’s write latencies.
Aerospike recovers from node failures by rebalancing partitions. If a node is taken down for maintenance, such as rebooting to apply a kernel patch, the system memory is wiped and has to be reconstructed by data over the network. While ASMT (Aerospike Shared-Memory Tool) exists to help persist indexes on a non-ephemeral disk, it needs additional steps around the activity.
If a whole Rack (or availability zone) goes down, the system has to migrate data from other nodes, often impacting cluster performance.
Rack Awareness is available on Enterprise with additional licensing.
ScyllaDB’s design is built around high-availability. Its leaderless approach and flash persistence means taking nodes out of the cluster is handled gracefully and without impacting applications’ availability or performance.
It supports Region and Rack awareness by default, both on ScyllaDB (for replication) as well as client-to-server communication (for networking within the same AZ).
Aerospike’s Strong Consistency mode, which is a paid add-on, prevents stale reads or data loss during a network partition. It also comes with a higher latency for writes, as the system involves more nodes in processing a write operation.
ScyllaDB offers fine-grained control over Consistency via the Consistency Level (CL). The CL applies on a per-query basis, so an application might have different CLs distributed along its processing path.
High availability within a single region usually means `LOCAL_QUORUM` is used to ensure replication happens to all racks (availability zones, in Cloud terms), while serving consistent reads locally under the same consistency level.
Aerospike uses a proprietary API and matching client libraries. An application built for Aerospike has its data layer permanently attached to Aerospike. Migrating away from it requires a massive rewrite of application (queries and logic) since no other product offers a compatible API.
ScyllaDB offers two of the industry’s most adopted protocol standards: CQL (the Cassandra protocol) and DynamoDB API.
This API compatibility means ScyllaDB users can use popular connectors such as Spark, Kafka, Trino/Presto and Temporal. (See more under Ecosystem and integrations)
Since Aerospike has a proprietary protocol, the surrounding ecosystem is very narrow. Integration with distributed stacks (such as Kafka, Spark, Presto/Trino) requires relying on Aerospike-provided custom connectors. Some of the most performant or reliable versions of these connectors are locked behind an Enterprise subscription. This ties the data processing infrastructure directly to the Aerospike license.
ScyllaDB inherits the ecosystem from mature Cassandra environments and a large DynamoDB deployment base. Its protocol compatibility allows leveraging connectors built for these products and removing barriers for adoption on various stacks.
Aerospike’s Community version lacks several basic functionality, such as compression, encryption at rest, multi-region replication, rack awareness for high availability. These features are all locked behind a subscription, with some even charged for separately. There is a premium for a minimum Enterprise-grade deployment.
ScyllaDB’s Free Tier has all features present. This includes advanced network and storage data compression algorithms, Enterprise-grade Encryption-at-Rest, Workload Prioritization, native cross-region replication, LDAP, and so many others.
Aerospike’s proprietary model means users have a steeper learning curve to learn the product, as they can’t access Production-ready features for local development without a commercial engagement. Hiring someone that is fluent on your database means hiring someone that specifically worked with Aerospike before.
ScyllaDB’s model means users can pick up the technology much faster and be ready to produce at a much higher pace. Developers can (and are encouraged to) run ScyllaDB instances on their own workstations or a small shared server – which helps them familiarize with the product environment and its inner workings as they develop an application.
“ScyllaDB is handling 340,000 OPS at just 21% CPU. This is high scale in action! ScyllaDB delivers microsecond writes and millisecond reads for us. This level of blazing fast performance is exactly why we chose ScyllaDB.”
Dean Poulin, Tripadvisor
“ScyllaDB provides the low latency that we need for ad serving. It linearly scales, both vertically and horizontally. We can also use workload prioritization to ensure that ad delivery is not impacted by our other data processing”
Brian Jones, SAS
“People all over the world are stressed watching this incredible match [the World Cup Final], but meanwhile, Discord and the ScyllaDB messages database aren’t breaking a sweat. We’re way up on message sends and handling it perfectly”
Bo Ingram, Discord
“We see about 4X less latency in reading from ScyllaDB compared to Redis. Overall, our mean latencies coming out of ScyllaDB are about 500 microseconds, and our P90 latencies are about 1-2 milliseconds. That’s 4-8X better than what we were seeing in our Redis setup”
Brendan Cox, Sprig
ScyllaDB delivers predictable performance at a fraction of Aerospike’s infrastructure cost by taking full advantage of modern hardware and CPU efficiency rather than relying strictly on a RAM-heavy architecture (like Aerospike does).
It accomplishes this through three core architectural mechanisms:
The fundamental difference is in resource management.
A use case is better suited to ScyllaDB when it requires massive dataset scaling, lower infrastructure costs, and complex data models.
ScyllaDB is the ideal choice for workloads that demand:
ScyllaDB’s TCO advantage is a direct result of its hardware efficiency at scale.
The Aerospike RAM Limitation: Aerospike’s highest-performance setups rely on primary indexes residing in RAM. As your dataset grows into terabytes, provisioning enough RAM quickly becomes very expensive.
The ScyllaDB Storage Advantage: ScyllaDB’s design, starting from its shard-per-core architecture, is designed to extract maximum performance from cost-efficient disks for both data and indexes.
The Bottom Line: By leveraging a cache rather than relying heavily on RAM, ScyllaDB delivers predictable latency on cheaper infrastructure, reducing required infrastructure and lowering TCO.
The fundamental difference lies in how each database balances fault tolerance against infrastructure costs.
