(Dgraph founder here)
> The decision to adapt GraphQL instead of supporting Cypher, what would you say were the big trade offs?
Cypher was built around SQL, with the idea that people are used to SQL. Therefore, by having something similar, people would find it easier to adapt. Many years later, I'd say it still hasn't gained as much popularity beyond Neo4j as sometimes projected.
We bet upon GraphQL in 2015, because it was easy to understand, worked with JSON and resulted in sub-graphs. While Cypher and Gremlin return lists of things. One can go from subgraph to lists, but not the other way around, because relationships are lost.
Within 3 years of draft spec, GraphQL has taken the developer world by storm. Developers find it easy to wrap their heads around and enjoy working with it. In fact, GraphQL+- (our language) has become one of the USPs of Dgraph.
> Would you say more that you can get Mongo and Redis (+redisgraph) users to switch to Dgraph, or instead more that the main customers for graph databases are still in school right now and deciding what tech skills will underpin their careers?
We have heard from many user who would have used MongoDB or SQL if not for Dgraph. With Mongo, you get scalability, but at the cost of query complexity and transactionality (/correctness). Keys and Docs are nice, but they don't let you use relationships to interact with a wider dataset. With Dgraph, you get scalability, while also gaining a much richer and sophisticated querying ability, transactionality (distributed txns), correctness without losing query performance. My blog post says more about this.
Redis is a cache, so people are not directly comparing it against Dgraph, a persistence-first database. One could use Redis to perhaps store Dgraph results.