ArangoDB 1.4 comes with asynchronous master-slave replication. The new replication feature should make it much easier to create a backup from a running ArangoDB server. For example, a second ArangoDB instance can now be used as a slave by cloning all data from the master. The slave will be populated in the background while the master is running and accepting requests – not disrupting the master operations.
UPDATE: ArangoDB 2 introduced sharding! Original blog post: In ArangoDB’s google group there was recently an interesting discussion on what ArangoDB should offer in terms of replication and sharding. For the rest of you who does not follow the posts in the group, I have copied Frank Celler’s answer into this post: Frank writes: We will start with a master-slave, asynchronous replication for 1.4. This has at least the following advantages: It is a good fit for most use cases. It will allow us to implement backup as “slave”. It easily gives you redundancy by setting up multiple instances. It gives you read-scaling. There are also drawbacks. For example, you need to manually select and switch masters in case of fail-over. However, restricting to a simple solution (which is still hard enough to implement) should allow us to release V1.4 this summer. If you think about MySQL, you will see that in most case a master-slave replication is sufficient. The next step will be master-master replication. This, however, requires more complex protocols like Paxos to elect a master and at least three nodes. We have to decide, if this will be in version 1.5 or maybe already 2.0. We have to see how much has to be changed.