Which Cosmos DB API to choose: NoSQL vs MongoDB vs Cassandra vs Gremlin vs Table
Verdict: Default to Cosmos DB for NoSQL for new apps. Otherwise match the API to the workload you are migrating from (MongoDB, Cassandra, Table Storage) or to graph data (Gremlin). Workloads needing complex multi-table joins belong in Azure SQL Database.
| Criterion | NoSQL | MongoDB | Cassandra | Gremlin | Table |
|---|---|---|---|---|---|
| Data model | JSON documents, queried with SQL-like syntax | MongoDB-compatible BSON documents | Column-family; rows in a table can differ | Vertices and edges (graph) | Key-value pairs by PartitionKey and RowKey |
| Choose when | Brand-new app; no existing database to match | Migrating an existing MongoDB app with minimal code changes | Migrating an existing Apache Cassandra app with minimal code changes | Connections between entities matter as much as the entities, e.g. a social network | Migrating an existing Azure Table Storage app for more scale and autoscale |
Rules
- Cosmos DB for NoSQL is the native API and the recommended default for brand-new applications, storing JSON documents queried with SQL-like syntax.
- To migrate an existing app with minimal code changes, match the API to the source database: MongoDB app to the MongoDB API, Cassandra app to the Cassandra API, Table Storage app to the Table API.
- Cosmos DB for Apache Gremlin models entities as vertices and relationships as edges, useful when connections matter as much as the data, such as a social network.
- Cosmos DB exposes exactly five APIs: NoSQL, MongoDB, Table, Apache Cassandra, and Apache Gremlin. There is no Oracle or SQL Server API.
- Workloads that depend on complex multi-table joins are better served by Azure SQL Database than by Azure Cosmos DB.
Traps
- Reusing existing MongoDB code against Cosmos DB for NoSQL still requires a rewrite, because NoSQL uses a different query syntax to MongoDB.
- The Gremlin API is not a fit for document workloads: it models graphs, not JSON documents queried with SQL-like syntax.
- Azure Table storage and the Table API are key-value stores with no support for multi-table joins, so they cannot replace a relational reporting workload.