We are proud to announce the beta release of ArangoDB 2.2. It is a major step forward, improving the usability of AQL and graphs a lot. As always, a lot of small improvements are incorporated into your favourite NoSQL database – we will list them in a separated blog entry. However, the three major improvements are a new and improved graph module modifying AQL a true write-a-head log While the latter is a big step on the way to automatic failover and synchronous replication, it is mostly hidden from the user. A more detailed description will follow in the next days. The new graph module is directly visible and intended to be used by you. Graphs are much more flexible now. You can easily use more than one vertex collection to group your vertex documents into “classes”. For example, for a bipartite graph, use two vertex collections – one for each part. You can even group your edges. Use one collection for each type (“friendship” and “alliance”). Or what about Graphs-on-Graphs! Why on earth would you like to do that? Well, consider a street map, where the junctions are vertices, the edges are street segments between junctions. Now put another graph on top, to model streets as segments – again more information is coming its way. The graph viewer works with these extended graphs and even allows you to explore sharded graphs with billions of nodes. With AQL you could always express joins, aggregate, traversals – all in a convenient query language, but only for reading. You can now also modify documents or create new ones using AQL. To copy a collection you can use FOR u IN collection INSERT u IN copy or create a projection FOR u IN _users INSERT { name: u.user } IN copy or update, or remove, or or or. The possibilities are endless. The beta version is a preview, it can be downloaded from https://www.arangodb.org/download2 Please do not use it in production. We plan to release the final 2.2.0 in a few days. Currently there are the following known issues: documentation is not yet complete the db.collection.rename() command is not honored when replaying a write-ahead logfile. If such rename operation is contained in a write-ahead logfile, it will not be re-executed on startup, and the collection might be present with the old name instead. the db.collection.properties(…) command is not honored when replaying a write-aheadaaa