- Is it lacking performance?
Not that I’ve found, but I echo @seanlaff 's comment above re: sharding on predicates. For us, this is a huge concern. The vast majority of our graph will only have a few predicates (xid being ubiquitous).
- Do you really need transactions?
Yes, if this is meant to be a production application database.
- Should Dgraph not be a database? Should it be a serving system instead?
We are looking for a graph database, not a graph layer on a relational database, if that’s what you meant.
- Should Dgraph interface with other databases better?
If Dgraph could ingest RDBMS schemas that would be interesting, though I don’t know how you would solve that.
- Does Dgraph not work with GraphQL properly? or React?
We are not interested in GraphQL as the main feature of Dgraph. We are looking for a massively horizontally scalable graph database that can do the high-performance graph traversal that an RDBMS isn’t tuned for. And in fact we prefer to use Dgraph Cloud rather than host it ourselves. It’s not an easy product to self-administer, and we’re thankful for the support.
In fact, the focus on GraphQL has been a little disappointing. We maintain a GraphQL schema just in case, but we use DQL exclusively.
The only wishlist item I have is a multi-RAFT approach for regional clusters like CockroachDB is doing, but it’s not at all a deal breaker.