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)
* a list of things they don't like in sql
* a list of traits they think a replacement should exhibit by negating the first list
I was kind of hoping for some example of what this much better language should look like
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.
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.
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
SQL isn't for everything.
Neither is starting with NOSQL thinking it might be better and then proceeding to spend way too many man years making it a relational database, when learning a bit of SQL would have handled it fine.
> The relational model is great ... but SQL is the only widely-used implementation of the relational model ...
I'm not too familiar with GraphQL but on the surface it seems like another bad idea. Shouldn't you always have some proper API abstraction between your components? 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. But the answer can't be have no APIs?
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.
EDIT: FWIW I do think SQL is pretty good at the job it is designed to do. Trying to replace it seems hard and with unclear value.
GraphQL was supposed to help front-end and back-end meet in the middle by letting front-end write specific queries to satisfy specific UX while back-end could still constrain and optimize performance. Front-end could do their work without having to coordinate with back-end, and back-end could focus on more important things than adding fields to some JSON output.
I think it's important to keep this context in mind to appreciate what problem GraphQL is solving.
This is also the motivation that would lead me to advocate for adopting GraphQL for a product. Moreso than a technical decision, it is an organizational decision regarding resource trade-offs, and where the highest iteration or code churn is expected to be located.
As I was saying, there might be some situations where that's the right thing, but in general it seems you want to have a well controlled layer there the specifies the contract between these pieces.
I was not intending to dodge your questions, but nor was I trying to comprehensively answer them, because they felt a bit unclear. I will make an attempt, combining snippets within your two posts that seem to be related:
>Shouldn't you always have some proper API abstraction between your components?
>But those endpoints are abstractions. Don't we want control over the surface of the API and our abstractions?
I can't answer this unless I know what concepts/layers you are referring to when you say "abstraction between components". If you mean "between the client and server", then yes, and GraphQL does this by way of the schema, types, and resolvers that the server supports, along with the query language itself. The execution is still occurring on the server, and the server still chooses what to implement and support.
If by "abstraction between components" you mean "URL endpoints and HTTP methods" then no, GraphQL chose to not have the abstraction be defined by the URL endpoint. If you use GraphQL, you do so having accepted that the decision point where resources are named is not at the URL or routing level. That doesn't make it not an abstraction, or not "proper" in some way.
>But the answer can't be have no APIs?
I don't understand what you mean by "No APIs"? You also mention "control over the surface"...
Is your concern that, because the client can ask the server "Please only respond with this subset of nodes, edges and properties: _______", the server has "no API"? Or it doesn't have "control"? I assure you that you can implement a server with whatever controls you desire. That doesn't mean it will always be easy, or be organized the way you are used to, or have the same performance profile you are used to, but the server can still implement whatever behavior it wants.
>...in general it seems you want to have a well controlled layer there the specifies the contract between these pieces.
I think this wording brings me closer to understanding your main concern.
First, let me repeat: I am not a big GraphQL fan, and am only explaining my understanding after implementing it on both clients and servers. I am not attempting to convince you this is good, only to explain a GraphQL approach to these matters.
The "well-controlled layer" is the edge between nodes, implemented as resolvers. This was the "aha" moment for me in implementing GraphQL the first time: edges are a first-class concept, not just the nodes/entities. If you try using GraphQL in a small project whose domain model has lots of "ifs" and "buts", you will be forced to reach for that layer of control, and get a sense of it. It is simply located in a different place than you are used to.
This "edges are first-class concepts" has an analogue in proper hypermedia REST APIs, but most organizations don't implement REST that way, so except for the five people who fully implement true HATEOAS, it is mostly beside the point.
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.
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
> 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
Generally, generating the JSON response directly for consumption in the DB is faster.
> 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
For instance, analytics usecases favor SQL stores, as slicing and dicing is better done with row or column stores instead of document databases.
Also, Postgres is getting more popular for lot of usecases, so SQL is here to stay.
(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.
Even though SQL as flaws, maybe a lot, it has one upside which is: it's so easy to onboard people on it, in the data ecosystem (warehousing etc.) it means that we can do way much stuff faster than before and hire less technical people, which is great
Standard SQL is not helpful, though. If that (failed) experiment was ended, database implementations would have even more freedom to explore superior syntax. Prescriptive language standards are a mistake.
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.
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.
...Or is that the joke?
Specifically: the connector bits that deal w/ translating Relational Algebra IR expressed as GraphQL nodes -> SQL engine-specific code.
The author's comments about lack of standardization and portability might not get across just how nightmarishly different SQL dialects are.
I might put together a list of some of the batshit-insane bugs we've run into, even between version upgrades of the same engine.
I really think folks would raise an eyebrow if they understood just how much variance exists between implementations in what might be considered "common" functionality, and the sorts of contortions you have to do to get proper shims/polyfills/emulations.
janpio•3h ago
j45•1h ago
bruce511•1h ago
Everything may have been true at the time of writing, but details may be obsolete. For example this article refers to Neo4j. Knowing the article is 4 years old helps me understand that comment is not current.
The landscape can change quickly. The older an article the more one takes that into account. Given that this article promotes an alternative technique, Knowing the article is old allows me to wonder if any of the suggestions were gelled, and if so to what success.
In this case, since SQL has been around since the 70s, it's not surprising that the complaints are not novel, and are all likely to be true for years to come. SQL has truly enormous inertia on its side though.
j45•2m ago