What you can’t do with Cassandra
- Multi-model: Cassandra is a partitioned row-store database. It does not support any other data model. If your application requires a graph or key/value store, you would have to use a second database technology like Titan or DataStax Enterprise Graph to support graphs, thereby adding complexity and costs. Being native multi-model, ArangoDB allows you to use one database for both and also run queries efficiently on data stored in different models.
- Unified Query Language: ArangoDB Query Language (AQL) supports all three data models (k/v, document, graph) with their respective data access patterns (Projections, Joins, Traversals, more). In addition, querying special data types like text or geo-spatial is natively supported by AQL. All data models and data types can be freely combined in a single AQL query. To do the same in Cassandra, one would have to learn CQL and Gremlin for graphs.
- Joins: Also various join operations are supported natively in AQL. ArangoDB even supports join operations at scale with the Satellite Collection feature. With Cassandra, these operations are not possible natively and have to be done client-side with all its security and performance impacts.
- Complex Transactions: Cassandra does not support ACID transactions. With ArangoDB, developers can use complex transactions to span multiple documents and collections, or to run aggregations. ArangoDB supports multi-document & multi-collection transactions (single instance; single document transactions in cluster setting).
- Scalability needs and ArangoDB: ArangoDB is cluster-ready for each model and multi-model usage. Unlimited scale-up capabilities thanks to C++ core balanced with scale-out. ArangoDB cluster architecture supporting independent scaling for serving high read/writes volumes and data storage, if needed.
- Extensibility: Use existing data-centric microservices or run your own in a dedicated JavaScript framework Foxx within ArangoDB, providing e.g. a single API call for complex graph traversals.
- Lower TCO: Knowing a multi-model database means applying the same knowledge to diverse use cases and lets developers move much faster. ArangoDB can be used for a broad range of different use cases with native multi-model approach and thereby simplify the needed tech stack and operational footprint.
Comparison table: Cassandra versus ArangoDB
| Feature | Cassandra | ArangoDB |
| General | ||
| Initial Release | 2008 | 2012 |
| License | Apache V2 / Commercial | Apache V2 / Commercial |
| Written in | Java | C++ |
| Data-Model | Partitioned
Row-store |
Native Multi-Model
(KV, Documents and Graphs) |
| Schema free | No | Yes;
Validation via JOI possible |
| Data format | Tabular | JSON / VelocyPack |
| Storage Engine | SST | MMFiles or RocksDB |
| Journaling | Yes | Yes |
| Cluster | ||
| Auto-Sharding | Yes | Yes |
| Replication | async (eventual only) | sync / async |
| Replication conflict resolution | Master/Master | Master/Master
Master/Agent |
| Scale-Out
(More machines) |
Yes | Yes |
| Scale-Up
(Bigger-Memory machines) |
Limitations Possible
(JVM heap limitations) |
No Limitations
(C++ based) |
| native Kubernetes / Mesos integration | Yes / Yes | Yes / Yes |
| Deployment modes | Cluster only ( 3 servers min) | Single Server, Active-failover & Cluster |
| Transactions | ||
| Transaction Model | BASE | ACID |
| Multi-Document Transactions | No | Yes*
(single instance) |
| Multi-Collection Transactions | No | Yes* |
| Querying | ||
| Declarative Query Language | Yes, CQL | Yes, AQL |
| Graph Traversals | Additional integrations needed | Yes; native AQL |
| Full-text Search | Basic Integration | ArangoSearch** |
| Joins | Additional integrations needed | Yes, native AQL |
| Advanced path-finding with multiple algorithms
(shortest path etc.) |
Additional integrations needed | Yes, native AQL |
| Indexing | Yes; mostly primary-key | Yes; Hash, Skiplist, Geo, Text, Vertex-Centric, etc |
| Geospatial (indexing / queries) | Additional integrations needed | Yes, native AQL |
| Extensibility | ||
| Microservice Support | No | Yes, Foxx Framework for data-centric microservices *** |
| Server-Side Functions | Yes | Yes |
| Spring framework support | Yes | Yes |
| Apache Spark support | Yes | Yes |
| Security | ||
| Encryption | TLS / SSL | TLS / SSL |
| Authentication | Yes | Yes |
| Role-based access control | Yes | Yes, even field level control possible**** |
| LDAP | Yes (Enterprise) | Yes (Enterprise) |
| Auditing | Yes (Enterprise) | Yes (Enterprise) |
| Administration | ||
| Web-based GUI (self-contained) | No | Yes |
| RESTful API | No | Yes |
| Zero Maintenance | No (manual anti-entropy repairs, etc.) | Yes |
| BackUp/Restore | Yes | Yes |
* In single server setups, ArangoDB supports full ACID transactions for multi-document & multi-collection transactions. In a cluster setup, ArangoDB only supports multi-document & multi-collection transactions for non-sharded collections. Single document transactions are supported for shared collections.* In single server setups, ArangoDB supports full ACID transactions for multi-document & multi-collection transactions. In a cluster setup, ArangoDB only supports multi-document & multi-collection transactions for non-sharded collections. Single document transactions are supported for shared collections.
** Including full-text search for arbitrary strings, prefix searches as well more advanced functionality like relevance, ranking, word normalization, removing stop-words, identifying word-boundaries that work across multiple collections. https://arangodb.com/2018/01/milestone-arangodb-3-4-arangosearch-information-retrieval/
*** Easily create a REST API for data centric use cases and add any missing functionality.
**** ArangoDB supports all basic security requirements. This includes LDAP-based authorization and User Management at database and collection levels. By using ArangoDB’s Foxx microservice framework, users can create even field-based access control.