Apache Cassandra and Amazon Keyspaces

Apache Cassandra is a distributed NoSQL database built around a wide-column data model. It runs across many machines with no single primary, which gives it linear write scalability and tolerance of node and datacentre loss — the properties that made it the default choice for very large, write-heavy workloads at companies such as Netflix.

Operating a Cassandra ring is the difficulty. Capacity planning, repair scheduling, compaction tuning, version upgrades and node replacement are ongoing work, and getting them wrong shows up as latency long before it shows up as an outage.

Amazon Keyspaces

Amazon Keyspaces (for Apache Cassandra) runs Cassandra-compatible workloads as a managed service. It implements the Cassandra Query Language and works with existing Cassandra drivers and tools, so applications connect to it much as they would to a self-managed ring.

• Serverless. There are no nodes to size, place, patch or replace. Tables scale up and down automatically in response to application traffic, and you pay for the throughput and storage actually used.
• Managed operations. No servers, no software patching, no repair or compaction scheduling.
• Availability. Data is replicated across multiple Availability Zones within a Region by the service.

The trade is compatibility. Keyspaces implements the CQL API rather than being Cassandra, so some behaviours, settings and newer CQL features differ. As with DocumentDB and MongoDB, the practical test is to run the application’s own test suite against Keyspaces rather than to reason about the version number.

When it is the right choice

Keyspaces suits a team that already has a Cassandra workload — or a genuinely wide-column, write-heavy access pattern — and does not want to run the ring. For a new application with no Cassandra history, DynamoDB covers most of the same ground with a deeper AWS integration and a larger body of guidance, and is usually the better starting point.