Jonathan Ellis

Today Amazon announced&nbsp;<a href="http://aws.amazon.com/DynamoDB">DynamoDB</a>, a hosted database for Amazon Web Services.

With DynamoDB, Amazon and Cassandra come full circle: just as Cassandra was inspired by Amazon's 2007 Dynamo paper, DynamoDB has adopted many of the improvements Cassandra has made since then.

Here's a summary of how DynamoDB compares to Cassandra:

<table>
	<tbody>
		<tr>
			<th>&nbsp;</th>
			<th>Cassandra</th>
			<th>DynamoDB
			&nbsp;
			</th>
			<th>&nbsp;</th>
		</tr>
		<tr>
			<td>Key + columns data model</td>
			<td><a href="https://www.datastax.com/docs/1.0/ddl/column_family">Yes</a></td>
			<td><a href="http://aws.amazon.com/DynamoDB/#details">Yes</a></td>
		</tr>
		<tr>
			<td>Composite key support</td>
			<td>Yes</td>
			<td>Yes</td>
		</tr>
		<tr>
			<td>Tuneable consistency</td>
			<td>Yes</td>
			<td>Most operations</td>
		</tr>
		<tr>
			<td>Distributed counters</td>
			<td>Yes</td>
			<td><a href="http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/WorkingWithDDItems.html">Yes</a></td>
		</tr>
		<tr>
			<td>Largest value supported</td>
			<td><a href="http://wiki.apache.org/cassandra/CassandraLimitations">2GB</a></td>
			<td><a href="http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/Limits.html">64KB</a></td>
		</tr>
		<tr>
			<td>Idempotent write batches</td>
			<td><a href="https://www.datastax.com/docs/1.0/references/cql/BATCH">Yes</a></td>
			<td>No</td>
		</tr>
		<tr>
			<td>Time-to-live support</td>
			<td>Yes</td>
			<td>No</td>
		</tr>
		<tr>
			<td>Conditional updates</td>
			<td>No</td>
			<td><a href="http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/WorkingWithDDItems.html">Yes</a></td>
		</tr>
		<tr>
			<td>Indexes on column values</td>
			<td><yes< td=""> </yes<></td>
			<td><a href="http://aws.amazon.com/DynamoDB/#access_model_api_overview">No</a></td>
		</tr>
		<tr>
			<td>Hadoop integration</td>
			<td>M/R,Hive,&nbsp;<a href="https://www.datastax.com/docs/1.0/datastax_enterprise/about_pig">Pig</a></td>
			<td>M/R,&nbsp;<a href="http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/EMR_Hive_Commands.html">Hive</a></td>
		</tr>
		<tr>
			<td>Multi-datacenter support</td>
			<td><a href="https://www.datastax.com/dev/blog/deploying-cassandra-across-multiple-data-centers">Full cross-region</a></td>
			<td>Mutiple availability zones only</td>
		</tr>
		<tr>
			<td>Integrated caching</td>
			<td><a href="https://www.datastax.com/dev/blog/maximizing-cache-benefit-with-cassandra">Yes</a></td>
			<td>Unclear</td>
		</tr>
		<tr>
			<td>High performance on commodity disks</td>
			<td>Yes</td>
			<td>N/A</td>
		</tr>
		<tr>
			<td>Monitorable</td>
			<td><a href="https://www.datastax.com/products/opscenter">Yes</a></td>
			<td><a href="http://aws.amazon.com/dynamodb/faqs/#How_do_I_monitor_table_size_and_performance">Yes</a></td>
		</tr>
		<tr>
			<td>Backups</td>
			<td>Low-impact snapshot + incremental</td>
			<td><a href="http://aws.amazon.com/DynamoDB/#access_model_api_overview">Manually with EMR</a></td>
		</tr>
		<tr>
			<td>Deployable</td>
			<td>Anywhere</td>
			<td>Only on AWS</td>
		</tr>
	</tbody>
</table>

Both Cassandra and DynamoDB achieve high scalablity, using many of the&nbsp;<a href="http://en.wikipedia.org/wiki/Gossip_protocol">same</a>&nbsp;<a href="http://en.wikipedia.org/wiki/Consistent_hashing">techniques</a>. Cassandra has been shown to scale to&nbsp;<a href="http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html">millions of ops/s</a>, and Amazon announced on this morning's webcast that they have a customer doing over 250 thousand op/s on DynamoDB. This kind of scale needs to be baked in from the start, not tacked on as an afterthought.

The multi-datacenter availability story is a bit more complex. DynamoDB replicates data "across multiple Availability Zones in a Region," but cross region is not supported. Since Availability Zones are not geographically dispersed, you need cross-region replication if you're worried about&nbsp;<a href="http://aws.amazon.com/message/65648/">outages affecting entire regions</a>&nbsp;or if you want to provide local data latencies to all your clients in any region. This requires the kind of fine-grained control over data consistency seen in Cassandra.

The data model is one area where DynamoDB is much closer to Cassandra than to the original Dynamo. The original Dynamo design had a primitive key/value data model, which has serious implications: to update a single field, the entire value must be read, updated, and re-written. (Other NoSQL databases have grafted a document API onto a key/value engine; this is one reason their performance suffers compared to Cassandra.) Another direct consequence is requiring complex&nbsp;<a href="http://pl.atyp.us/wordpress/index.php/2010/03/conflict-resolution/">vector clocks</a>&nbsp;to handle conflicts from concurrent updates to separate fields. Cassandra was one of the first NoSQL databases to offer a more powerful ColumnFamily data model, which DynamoDB's strongly resembles.

However, secondary indexes were one of the best-received features when Cassandra introduced them a year ago. Going back to only being able to query by primary key would feel like a big step backwards to me now.

Like Cassandra, DynamoDB offers Hadoop integration for analytical queries. It's unclear if DynamoDB is also able to partition analytical workloads to a separate group of machines the way you can with Cassandra and&nbsp;<a href="https://www.datastax.com/products/enterprise">DataStax Enterprise</a>. Realtime and analytical workloads have very different performance characteristics, so partitioning them to avoid resource conflicts is necessary at high request volumes.

Hadoop is rapidly becoming the industry standard for big data analytics, so it makes sense to offer Hadoop support instead of an incompatible custom API. It's worth noting that Cassandra supports&nbsp;<a href="http://pig.apache.org/">Pig</a>&nbsp;as well as Hive on top of Hadoop. Many people think pig is a better fit for the underlying map/reduce engine.

Cassandra has been in production in many demanding environments for years now, so it's no surprise that Cassandra has a substantial lead in delivering real-world features like backup. Cassandra's log-structured storage engine-- which is also the reason Cassandra runs so performantly without SSDs -- allows both full and incremental backups with no impact on performance. (You can then upload your backup files with a tool like&nbsp;<a href="https://github.com/synack/tablesnap">tablesnap</a>).

As an engineer, it's nice to see so many of Cassandra's design decisions imitated by Amazon's next-gen NoSQL product. I feel like a proud uncle! But in many important ways, Cassandra retains a firm lead in power and flexibility.

Temporal Supercharges Developer Agility

Temporal powers high growth apps like Netflix and Instacart.

Learn about NoSQL Databases

Learn about NoSQL databases with Apache Cassandra and Astra DB.

2022 Recap: A Year for Customers, Community, and Real-Time Data

Highlights from 2022 and a glimpse into the year ahead.

ViewingIndustry

Amazon DynamoDB

Sign up for our Developer Newsletter