ArangoDB isn't the only tool in town trying to mix the power of graph and document databases. OrientDB does something similar, but packages itself as a "second-generation graph database." In other words, the nodes in the graphs are documents waiting for arbitrary key-value pairs.
This makes OrientDB feel like a graph database first, but there's no reason you can't use the key-value store alone. They also include a RESTful API waiting for your queries.
How many times have you found yourself wishing for the power of a search engine like Lucene but with the structure and querying ease of SQL? If the answer is more than zero, Crate.io may be the answer.
While Lucene began as a search engine for finding keywords in large, unstructured blocks of text, it's always offered to store keys and matching values in each document, allowing some to consider it part of the NoSQL revolution. Crate.io started with Lucene and its larger, scalable, and distributed cousin Elasticsearch but added a query language with SQL syntax. The folks behind Crate.io are also working on adding JOINs, which will make Crate.io very powerful -- assuming you need to use JOINs.
People who love the old-fashioned SQL way of thinking will enjoy the fact that Crate.io bundles newer, scalable technology in a manner that's easier for SQL-based systems to use.
The name might not be appealing, but the sentiment is. CockroachDB’s developers embraced the idea that no organism is as long-lasting or as resilient as the cockroach, bragging, "CockroachDB allows you to deploy applications with the strongest disaster recovery story in the industry."
While time will tell whether they've truly achieved that goal, it won't be for lack of engineering. The team’s plan is to make CockroachDB simple to scale. If you add a new node, CockroachDB will rebalance itself to use the new space. If you kill a node, it will shrink and replicate the data from the backup sources. To add extra security, CockroachDB promises fully serializable transactions that are across the entire cluster. You don't need to worry about the data, which incidentally is stored as a "single, monolithic map from key to value where both keys and values are byte strings (not unicode)."
In a traditional database, you send a query and the database sends an answer. If you don't send a query, the database doesn't send you anything. It's simple and perfect for some apps, but not for others.
RethinkDB inverts the old model and pushes data to clients. If the query answer changes, RethinkDB sends the new data to the client. It's ideal for some of the new interactive apps that are coming along that help multiple people edit documents or work on presentations at the same time. Changes from one user are saved to RethinkDB, which promptly sends them off to the other users. The data is stored in JSON documents, which is ideal for Web apps.
Sign up for CIO Asia eNewsletters.