Cassandra-Compatible Database - Serverless Distributed Database with Amazon Keyspaces
Learn how to design and operate distributed databases using Amazon Keyspaces (for Apache Cassandra) and DynamoDB.
Apache Cassandra and Amazon Keyspaces
Apache Cassandra is a NoSQL database known for high write throughput, linear scalability, and multi-region replication as a large-scale distributed database. It has been widely used as the foundation of large-scale services for write-heavy uses such as time-series data, event logs, and message history, but operating it on-premises requires deep expertise. Operational tasks are extensive, including data rebalancing during node additions and removals, compaction strategy optimization, tombstone management, and JVM tuning. Amazon Keyspaces is a fully managed database service compatible with Apache Cassandra that lets you use CQL (Cassandra Query Language) as-is. You can use existing Cassandra application drivers and tools with minimal modifications, dramatically reducing operational overhead while preserving Cassandra's data model and query patterns. With its serverless architecture, you can start reading and writing data immediately after creating a table, with no need to pre-provision capacity.
Amazon Keyspaces Features and Architecture
Amazon Keyspaces operates in a serverless manner, automatically scaling table throughput based on traffic. In on-demand mode, you pay per read/write request, minimizing costs during low-traffic periods. Provisioned mode offers cost-efficient pricing for predictable workloads. Storage expands automatically, and data is replicated across three Availability Zones within a Region with a replication factor of 3. The availability SLA has two tiers depending on the configuration: the Service Commitment in the official SLA (updated May 24, 2023) sets a monthly uptime of 99.99% for the Standard SLA, which applies to single-Region configurations, and 99.999% for the Multi-Region Replication SLA, which applies when multi-Region replication is configured. Note that replication across three AZs supports durability within a single Region and is not in itself the basis for 99.999%. Encryption is enabled by default for both data at rest and in transit, with the option to use customer-managed keys via AWS KMS. Keyspaces supports the CQL 3.11 API (backward compatible with 2.x), and table definitions, data types, and query syntax are compatible with Cassandra. Conditional writes with lightweight transactions (LWT), such as IF NOT EXISTS, and the counter type are both supported, and there is no additional charge for using LWT. However, writes whose condition evaluates to FALSE still consume write units according to the row size, so you monitor the number of failures with the CloudWatch ConditionalCheckFailed metric. Features listed as unsupported in the official compatibility table (as of August 2026) include secondary indexes (CREATE INDEX / DROP INDEX), materialized views, triggers, user-defined functions (UDFs) and aggregate functions, ALTER TYPE, and TRUNCATE. Static columns, TTL, LOGGED / UNLOGGED BATCH, and user-defined types (UDTs) are available. Point-in-Time Recovery (PITR) lets you restore a table to any point within the past 35 days, making it easy to recover from accidental operations or data corruption. Here is an example of creating a table in Keyspaces using CQL: CREATE TABLE my_keyspace.orders ( customer_id text, order_id timeuuid, product_name text, quantity int, total_amount decimal, PRIMARY KEY (customer_id, order_id) ) WITH CLUSTERING ORDER BY (order_id DESC) AND CUSTOM_PROPERTIES = {'capacity_mode': {'throughput_mode': 'PAY_PER_REQUEST'}};
Migration Strategy from Cassandra to Keyspaces
A phased approach is recommended for migrating from an existing Cassandra cluster to Keyspaces. First, verify connectivity to Keyspaces using cqlsh or DataStax drivers and confirm schema compatibility. For data migration, there are two approaches: batch migration using AWS Glue, and gradual migration using dual writes (writing to both databases simultaneously). When using Glue, you configure an ETL job that reads data from Cassandra and writes it to Keyspaces. For large dataset migrations, it is efficient to secure sufficient write capacity in Keyspaces provisioned mode and switch to on-demand mode after migration is complete. Application-side changes are minimal. The main changes are updating the connection endpoint and configuring TLS (which is required for Keyspaces). During migration performance testing, it is important to test with Keyspaces' handling of consistency levels in mind. Writes are always performed at LOCAL_QUORUM for durability, and for reads you choose from three levels: ONE, LOCAL_ONE, and LOCAL_QUORUM (the default is determined by the driver settings, so specifying it explicitly is safer). Each 4 KB read consumes 0.5 units at ONE / LOCAL_ONE and 1 unit at LOCAL_QUORUM, so check the trade-off between consistency requirements and latency and cost before migrating.
Choosing Between Keyspaces and DynamoDB
When selecting a distributed database on AWS, both Keyspaces and DynamoDB are candidates. Keyspaces is ideal as a migration target for existing Cassandra applications, allowing you to leverage your CQL knowledge and skills directly. You can maintain Cassandra-specific data modeling patterns such as composite partition keys, clustering columns for flexible data modeling, TTL (Time to Live) for automatic data expiration, and static columns for partition-level shared data. Keyspaces also supports multi-Region replication: in an active-active configuration, each Region processes reads and writes independently, and conflicts are resolved automatically by last writer wins. Replication lag between Regions is typically under 1 second, the RPO during a Regional outage is a few seconds, and failover only requires switching routing with Route 53 (no promotion or failover operation is needed). However, constraints listed in the official documentation (as of August 2026) include the following: TTL must be set when a multi-Region table is created and cannot later be enabled, disabled, or changed; encryption at rest supports only AWS owned keys, not customer managed keys; synchronous replication and QUORUM consistency are not supported; and AWS GovCloud (US) and the China Regions are not covered. On the other hand, DynamoDB, as an AWS-native service, provides seamless integration with Lambda, AppSync, API Gateway, and more. Its strengths lie in AWS ecosystem integration, including DynamoDB Streams for event-driven architectures, global tables, and DAX (DynamoDB Accelerator) for microsecond-level caching. For new development by teams without Cassandra experience, DynamoDB is recommended; for migrating existing Cassandra workloads, Keyspaces is the better choice. Both services support IAM authentication, VPC endpoints, and encryption, meeting enterprise-level security requirements.
Keyspaces Pricing
The following rates are based on the official AWS pricing page as of August 2026, listed for N. Virginia (us-east-1) and Tokyo (ap-northeast-1). In on-demand mode, reads cost $0.125 (N. Virginia) / $0.1425 (Tokyo) per million read request units, and writes cost $0.625 (N. Virginia) / $0.715 (Tokyo) per million write request units. Provisioned mode is billed at hourly rather than monthly rates: $0.00013/hour (N. Virginia) / $0.0001484/hour (Tokyo) per read capacity unit (RCU), and $0.00065/hour (N. Virginia) / $0.000742/hour (Tokyo) per write capacity unit (WCU). The write rate is about 5 times the read rate; on a 730-hour monthly basis in N. Virginia, one RCU comes to about $0.095 and one WCU to about $0.475. Storage costs $0.25 (N. Virginia) / $0.285 (Tokyo) per GB per month, PITR backup storage $0.20 (N. Virginia) / $0.228 (Tokyo) per GB per month, automatic deletion by TTL $0.275 (N. Virginia) / $0.315 (Tokyo) per million items, and restoring from a backup $0.15 (N. Virginia) / $0.171 (Tokyo) per GB. Tokyo is roughly 10% to 20% more expensive than N. Virginia, so if your latency requirements allow, the choice of Region itself makes a cost difference. The pricing structure is nearly identical to DynamoDB, but the advantage is lower migration costs for existing Cassandra workloads since you can access data via CQL.
Summary - Choosing the Right Cassandra-Compatible Database
By choosing between Keyspaces as a Cassandra migration target and DynamoDB as an AWS-native option based on your workload characteristics and existing assets, you can build an optimal distributed database strategy. If CQL compatibility is required, Keyspaces is the right choice; if you prioritize serverless flexibility, DynamoDB is the better fit.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.