[curryst]

> No. You miss the point. SQL has proven robust over a broad set of types of data. People have tried to come up with new systems for objects (OODB), JSON documents (Mongo), and so on. All were disasters. It turned out SQL was the answer all along.

Document DBs have failed in the general case because most data is relational. OODB is still alive and well; Postgres implements some OODB features, and I would argue graph databases are an implementation of an OODB.

I also think you're lumping SQL and RDBMS together into one term. It's entirely possible to have an RDBMS that does not use SQL; likewise it's possible to have a system that is not an RDBMS that does use SQL. There are addons for MongoDB that let you speak SQL to it.

> I'll believe GraphQL is better when I see a case when it works better. So far, the only cases I've seen were from people who didn't fully grok SQL.

Most of the advantages come from introducing an intermediary data broker (the GraphQL server). As a query language, I do find GraphQL drastically simpler than SQL. We can compare queries for a person, their parents, and their children. I can guarantee the GraphQL query is shorter and more legible. That comes at the cost of flexibility, which I wholly acknowledge.

> I'll mention GraphQL has a completely separate use-case as a replacement for RESTful APIs, where it's not really acting so much as a query language as an API layer. I think it might have some uses there, but as nedbat points out in the thread, it'd be possible to use SQL as a replacement for RESTful APIs too, and it'd probably do better than GraphQL (before you start screaming about security, read netbat's posts; he is definitely NOT talking about a thin layer over a database).

This is the only use case that I'm aware of. There is dgraph, which is a graph database that speaks in GraphQL natively, but they've basically just integrated the API server into the database itself (which I'm not arguing for or against, I just think it's still basically the same stack).

[ken]

> It's entirely possible to have an RDBMS that does not use SQL

It’s not just theoretical. That’s what Postgres was.