The way I've heard this phrased is, for potential customers to justify switching to your solution, it can't be 10% better, it needs to be 10x better.

(And on top of that they need to clearly perceive the value of Strange New Thing, and clearly perceive the relative lack of value of the thing they have been emotionally invested in for decades...)

  > This is compounded by the standardized SQL-centric database driver APIs like ODBC and JDBC.

Newer platforms like Arrow ADBC/FlightSQL are better-suited to high-volume, OLAP style data queries we're seeing become commonplace today but the ecosystem and adoption haven't caught up.

https://arrow.apache.org/adbc/current/index.html

https://arrow.apache.org/docs/format/FlightSql.html

Thanks! Macroexpanded:

Against SQL (2021) - https://news.ycombinator.com/item?id=43777515 - April 2025 (1 comment)

Against SQL - https://news.ycombinator.com/item?id=40454627 - May 2024 (1 comment)

Against SQL (2021) - https://news.ycombinator.com/item?id=39777515 - March 2024 (1 comment)

Against SQL - https://news.ycombinator.com/item?id=27791539 - July 2021 (339 comments)

Much of the critique is that it's large and complicated because of bad design.

"Because SQL is so inexpressive, incompressible and non-porous it was never able to develop a library ecosystem. Instead, any new functionality that is regularly needed is added to the spec, often with it's own custom syntax. So if you develop a new SQL implementation you must also implement the entire ecosystem from scratch too because users can't implement it themselves.

This results in an enormous language."

> All that said there might be some situations where your goal is to query raw/tabular data from the client. If that's your application then APIs that enable that can make sense. But most applications are not that.

IME, the majority of responses sent to the client is tabular data hammered into a JSON tree.

If you generalise all your response to tabular data, that lets you return scalar values (a table of exactly one row and one column), arrays (a table of exactly one row with multiple columns) or actual tables (a table of multiple rows with multiple columns).

The problem comes in when some of the values within those cells are trees themselves, but I suspect that can be solved by having a response contain multiple tables, with pointer-chasing on the client side reconstructing the trees within cells using the other tables in the response.

That would still leave the 1% of responses that actually are trees, though.

  > My sense for this has been like GraphQL was invented out of the frustration of the frontend team needing to rely on backend teams for adding/changing APIs.

It's no different ideologically from gRPC, OpenAPI, or OData -- except for the ability to select subsets of fields, which not all of those provide.

Just a type-documented API that the server allows clients to introspect and ask for a listing of operations + schema types.

GQL resolvers are the same code that you'd find behind endpoint handlers for REST "POST /users/1", etc

Instead of a client dealing with a server that only presents unopinionated, overly-broad CRUD endpoints for core entities/resources, GraphQL is a tool through which the client tricks the server into creating a bespoke viewmodel for it.

I hold a very unpopular opinion of GraphQL. I think it’s a great internal querying API. Every web backend project I’ve worked on tries to implement an API for querying data and it’s usually either fast and inflexible or flexible but slow. GraphQL allows to strike a balance, flexible and reasonably fast, with ways to optimise further.

Re: GQL - Explain to me what abstraction layer should exist between the data model and what data is loaded into the client? I’ve never understood why injecting arbitrary complexity on top of the data model is wise.

Perhaps unfettered write access has its problems, and GQL has permissions that handle this issue plenty gracefully, but I don’t see why your data model should be obfuscated from your clients which rely on that data.

SQL itself doesn't generate any value, relational databases generate value. SQL is just a frontend for them. Anyway, your snark could be applied to _literally any change_. Are you angry that cars are replacing horses? "Horses generate such incomparable value that there's a steady supply of pro-car posts, like fumes from the vast ocean of their constantly boiling piss". Don't like the cotton gin? "Slave labor generates such incomparable value...". There's not really anything of substance in this kind of comment.

> Thing is it's good enough and extremely widely used.

The real problem is not that "it is good enough"; it's that SQL is still better than many of the newer proposals.

I mean, sure, if newcomer tech $BAR was slightly better than existing tech $FOO, then maybe $FOO might be eventually replaced. What we are seeing is that the newcomers are simply not better than the existing $FOO.

It’s not a small decision to switch database vendors.

Worrying that your data query language works across multiple vendors DB’s is not a concern ever considered imho.

> So I guess the author is trying to help a decision maker to make a decision when faced with a question of whether to use SQL or not.

That's not my impression. A decision maker today should typically make the decision to use SQL. I'm pretty sure the author would agree with that.

I think the target audience is language designers and tool builders. The author is urging people to envision and build new better interfaces to interact with relational data.

Trying to understand how the year is relevant - still new to folks and still seems relevant.

I like that SQL is a standard, and it's mostly "fine". Sure, I have to constantly read the man pages because there are half a dozen different ways to do fundamentally similar things, and there are subtle differences between each vendor, and I keep running into silly errors like trailing commas. But it mostly works.

The stuff that is more painful is building any kind of interesting application on top of a database. For example, as far as I know, it's very hard to "type check" a query (to get the "type" returned by a given query). It's also hard to efficiently compose SQL. And as far as I know, there's no standard, bulletproof way to escape SQL ("named parameters" is fine when you need to escape parameters, but most of SQL isn't parameters). There's also no good way to express sum types (a "place" can be a "park" or a "restaurant" or a "library", and each of those have different associated data--I don't need a "has_cycling_trails" boolean column for a restaurant, but I do for a park). There are various workarounds, all deeply unsatisfying.

I use Postgres JSON functions to return nested results. The database itself contains no JSON; just a well-normalised data model. However, the queries return nested JSON in the format required by the application, e.g. for rendering an HTML template or returning JSON to the client in a single round trip. Check out the old dogs can sort of learn new tricks in this great article: https://www.scattered-thoughts.net/writing/sql-needed-struct...

  > what is the upside of working with JSON in SQL over having your app construct and parse JSON objects, but storing the data in a database using more primitive types? 

Think usescases like: Allowing users to write configuration rules, or lists of custom tag <-> value pairs for (whatever), things of these sorts

I've occasionally stored JSON directly in a database. It really depends on what you do with this data. If you do need to query and manipulate the internals of that JSON object then you should extract that data into a proper schema. But sometimes e.g. this is just something the frontend uses and you never (or rarely) have to query the internals, i.e. you treat it as an opaque blob.

The post is not against the relational model. It's against SQL.

> The relational model is great ... but SQL is the only widely-used implementation of the relational model ...

I like PRQL[0] - fixes stupid warts about SQL.

A few top line items:

  - trailing commas not an error
  - queries can be read/written in linear order, starting with from, and ending on select
  - trivial intermediary keywords (eg you define month_total, and then can re-use month_total in a following calculation, no need to duplicate the calculation logic)
  - no need for a separate `having` keyword when `where` can just be a filter on a group

[0] https://prql-lang.org/

I think the much better language would be the "no language" database. Throw portability to the wind and just have the client ship the query plan directly. The frontend to the database is howerver you want to expose it in your language of choice. I don't think there's any hope of getting disparate db vendors to agree on a compatible frontend language. It seems easier to externalize it.

The closest existing database to this ideal is probably FoundationDB although it also externalizes the query planner, which I don't necessarily consider a downside.

Maybe I'm holding TFA wrong but to me it seems like they're hinting at wanting a Prolog-as-database that could also become widely used, unlike actual Prolog.

It's not hyper-performant and mega web scale but the object database and Prolog like query language that comes with Picolisp is quite fun and sometimes rather useful, and has helped me think differently about how to model things in the default SQL database engines.