I was hoping to hear about real-world use-cases. It's hard to make a commitment to a nascent technology, when there are already more established solutions, if they are flawed in some way that can be worked around... or if the performance hit is acceptable... or where the benefit of switching is hard to visualize.

It was probably a misstep to criticize Google, as you did in the link in my post. Your ressentiment only highlighted that respected people at Google voted against your technology. It did catch my attention, but it might have burnt some bridges, and left me with a lingering question mark.

I think if you're sincere about adoption of your technology, it has to be couched in clear terms of how it will fulfill business needs, and I'd like to see that. I'm intrigued by this performance gain, but I need a strong argument to help me decide if it's worth the opportunity cost to try Dgraph to make something.

This blog post explain the business needs that Dgraph is solving for: https://dgraph.io/blog/post/how-dgraph-labs-raised-series-a/

My comments about Google were accurate. I want to avoid saying anymore on that topic, because that's not my point here.

Thanks for the link. It does indeed illuminate business utility. A problem (for you, not me), is that people might realize they need a dedicated graph database down the track after they've built their infrastructure around a typical RDBMS. Might be a foolish question, but do you have any tooling/strategies that help an org transition to Dgraph, or use it parasitically? Seems if an org could get a taste of what Dgraph could do for them, they'd be more likely to invest in it.

> My comments about Google were accurate.

Accuracy wasn't the issue.

I look forward to seeing where Dgraph goes, and I might give it a try in the future.

So far we have been focused on delivering to folks who already are convinced about graphs. We absolutely need to do a better job at selling Dgraph and showing value early on to the orgs who don't yet understand the need for a graph solution. Our foray into GraphQL is a step in that direction, but we need to do more education.

Modern RDBMS's can now address "graph"-like schemata and use cases via recursive queries, which are part of the SQL standard. No need for a separate abstraction on top of it, much less for "processing of data at the abstraction layer".

> No need for a separate abstraction on top of it

I'm guessing the abstraction has now been internalized. Unless the representation and operations underneath have been customized, and provide the same transaction guarantees and parsimony that a native graph database would for graph operations.