Congrats on funding round, we need more options in this space. I'm a Neo user today, and I've said before that while I don't think most people will switch to graph databases, at some point I do think most new projects will use them. I chose Neo precisely because of py2neo.
The decision to adapt GraphQL instead of supporting Cypher, what would you say were the big trade offs?
As a startup, your price point is in the 20k/y ballpark, but GrapheneDB/Neo comes in a lot lower. What would I get for paying that much more?
I find that the audience for something that operates at the level of abstraction that a graph does tends to be different than the user who makes decisions based on lower-level features. e.g. design level problems vs. optimization problems.
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?
Fascinating space and looking forward to trying the product.
> 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.
Hey Manish! Congratulations to you and your team on the round! It's a phenomenal achievement.
You mentioned transactions... I work for MongoDB so I just wanted to add that MongoDB does have ACID transactions since version 4.0. Distributed transactions will be included in the upcoming 4.2 release. There's more info on distributed transactions in the 4.2 release here if you're interested: https://docs.mongodb.com/master/core/transactions/
By the way, it's awesome to see you're using Go. I just got into it recently and it's such a nice language to work with.
If anyone on your team is interested, we are working on a new plain text graph database called TreeBase: https://treenotation.org/treeBase/. Perhaps there are ideas you all could take away that would help make your products better.
I've been following Dgraph for a while and your GraphQL+- iteration on GraphQL. Clearly you folks understand the semantics and how to build a database that can handle massive scale.
Our focus is on much smaller databases (at the moment, nothing larger than what would be a few million rows), but I think the syntax we have makes the whole thing easier to understand and makes data more accessible to users. Maybe this is completely irrelevant, but if there might be something of value to your users here, feel free to have someone get in touch: yunits@hawaii.edu. (we are trying to get help advancing the state of the art in DB to make cancer and medical research easier)
Redis is much more than a cache, you can model graph data structures with Redis primitives, and the redisgraph module compares directly against Dgraph.
The entire graph is stored in memory and only spans one server. I personally am not sure what happens when that server goes down. How many minutes worth of data is lost? What's the replication strategy for another server to take over the traffic? And what about transactions and correctness?
Those things matter a lot to Dgraph users who are storing and serving their source of truths. Horizontal scalability, persistence, correctness and avoiding downtime with consistent replication have been cornerstones for the design of Dgraph.
It's a bit disappointing that you would talk down a competitor without knowing much about them, and then, to add insult to injury speculate about all kinds of things without having facts to diss them some more.
I'm more disappointed that a founder answering questions has somebody jumping down their throat for a perceived slight in a tiny portion of their reply. But that's HN.
You're misinterpreting me. I haven't talked down about them. And definitely don't think of them as a competitor.
My point was that those questions I mentioned above are important to Dgraph users and I don't think Redis even projects itself as a persistence-first DB. I might be wrong. Either ways, our audience is quite different when it comes to enterprises at least.
I know the founders of Redis Labs, met them as well and they're awesome people.
Thanks! We're very happy to finally share the announcements.
We bet on GraphQL very early on, right after the initial specs came out, as their language was surprisingly similar to what we were working on. We have not looked back since then, as GraphQL growth is pretty impressive as the creation of GraphQL foundation.
We are considering supporting cypher because many people are actually quite used to it, it's an open specification, and would also help us make more "apples to apples" comparisons with other databases (hi, Neo4j!).
For now, though, we're focusing on providing native support for pure GraphQL (not only GraphQL+-) but we don't discard adding Cypher later on.
As for the pricing, this is for a cluster with 2 nodes (1 alphas + 1 zero) and includes support and access to enterprise features. This, actually, ends up being often more affordable than our competition (or so our customers have told us).
We believe it's time for Graph DBs to become the default storage system, in the same way people consider SQL and no-SQL options nowadays, so our target audience is much wider than just people interested on graph databases.
Lastly, regarding Mongo + Redis I was not aware of this so I'll be checking it out soon and then I can give you my opinion :)
Happy to continue the conversation on slack.dgraph.io or discuss.dgraph.io!
FWIW, I would LOVE to see openCypher supported on dgraph! I find it far more expressive and easier to work with for many types of traversals and logical operations.
Very cool, thank you. I'm also eyeing the Janus graph for my next project, mainly because I'm interested in the Compose platform, and it's nice to have competing approaches. Will watch closely.
> As a startup, your price point is in the 20k/y ballpark, but GrapheneDB/Neo comes in a lot lower. What would I get for paying that much more?
Should have tackled this in my other post. But, let me approach this question from two angles.
Is it worth paying $20K for any DB or DB support? If it would save you 1/10th of an engineer per year, it becomes immediately worth. That means, can you avoid 5 weeks of one SWE by using a DB designed to better suit your dataset? If the answer is yes (and most cases it is), then absolutely that price is worth. See my blog post about how much money it must be costing big companies building their graph layers.
Second part is, is Dgraph worth paying for compared to Neo or others? Note that the price is for our enterprise features and support. Not for using the DB itself. Many companies run a 6-node or a 12-node distributed/replicated Dgraph cluster and we only learn that much later when they're close to pushing it into production and need support. They don't need to pay for it, the distributed/replicated/transactional architecture of Dgraph is all open source.
How much would it cost if one were to run a distributed/replicated setup of another graph DB? Is it even possible, can it execute and perform well? And, when you add support to that, what's the cost?
I have no doubt, when you consider the factors of scalability, Dgraph comes out much cheaper.
Neo4j basically only runs in single-node mode with optional replication for failover. You can't really do distributed graph queries without losing all the advantages of a graph db (namely following links is constant-time).
I haven't looked at DGraph much but if they are trying to store the graph in a distributed manner then the use-cases will be different.
From experience, using GrapheneDB/Neo4j takes much less than 1/10th of an engineer / year to manage, so unless your data doesn't fit in 1 box you'd be better off with Neo4j
Isn't this the trap that most startups fall in? "We don't have the money but we do have the engineers, lets build our own in-house solution for cheaper"
20k per year seems like an incredibly reasonable price for a managed distributed cloud store, especially when considering maintenance cost.
> If it would save you 1/10th of an engineer per year, it becomes immediately worth.
This ignores second-order effects.
Is it worth limiting yourself to an ecosystem with only users who are ok paying $20k per year, with "open source" development but all development activity done by one company that is trying to make a profit off something unproven, and then tie your core business data to it? Maybe. Not so clear cut though.
The decision to adapt GraphQL instead of supporting Cypher, what would you say were the big trade offs?
As a startup, your price point is in the 20k/y ballpark, but GrapheneDB/Neo comes in a lot lower. What would I get for paying that much more?
I find that the audience for something that operates at the level of abstraction that a graph does tends to be different than the user who makes decisions based on lower-level features. e.g. design level problems vs. optimization problems.
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?
Fascinating space and looking forward to trying the product.