Thanks @mohitranka for summarizing the discussion along with relevant data points about what others are doing.
I think Cayley, TitanDB etc., already have gone down the path of multiple backends – So, there are already plenty of options to choose from, if that’s what one wants to achieve.
With Dgraph, we want to achieve a tighter coupling between the system and the disk – what that means might not be immediately clear given the current code base. Currently, there is an obvious divide between Dgraph and underlying storage on disk. But, we want to reserve the right to make changes to this in ways that might make this division less so.
You can think of it in that way, but more importantly, RocksDB performs. It’s already being used at Google, Facebook and other DB companies (CockroachDB). BoltDB has design issues that I consider deal breaker for what we’re trying to achieve here with Dgraph – distributed, low latency, high throughput graph database. And I don’t want to qualify it to; it’s high throughput only if you don’t do writes.
BoltDB has no other advantage on top of RocksDB, except that it avoids Cgo. One has to copy values from C to Go in RocksDB. Initially, I’d expected that avoiding a value copy might be one of the advantages, given BoltDB is in Go space. But, that’s not the case. BoltDB also requires a copy to use the values safely. GitHub - boltdb/bolt: An embedded key/value database for Go.
We’re just cutting a release for v0.4, which will provide binaries that make it easier to run Dgraph. Embedding Dgraph in the client application is not recommended as of now. The Dgraph binary clients should provide good enough performance and avoid bringing in all the dependencies of Dgraph in your application.
Quick point about async: Every write to Dgraph first gets written to a commit log and flushed out to disk. Then it gets applied to the posting list. Periodically, posting lists get merged back to RocksDB. The writes are async. This is okay because even if the machine crashes, the commit logs would still have those writes, and when the posting list is initialized again, it would pick up those writes and apply them back. So, there’s no data loss.