SQL is what it is today because it is battle tested and has to handles a very hard problem of handling arbitrary concurrent reads/writes, so the likely scenario is that trying to replace general SQL wholesale will just end up making a worse, less tested version of SQL that developers are less familiar with. So, I think the best query language is probably whatever query feature that's already in your backend language, LINQ for C# for example. The only room for an SQL replacement in my opinion is if you are willing to trade flexibility for speed a la TigerBeetle.

The good thing about having built your own programming language via LLM nowadays is that you don't really have to speculate about a theoretical language when you can just have Codex/Claude implement it and try it out for yourself. I did it yesterday when I wanted to try out this theoretical high-performance database architecture that I had in mind and just added query functionalities to the language I already have.

If anyone is interested about the results, the default naive mode for this new database is ~0.2x the speed of concurrent durable mutation workloads, but if you specialize it to the particular application, you can get ridiculous 50-100x performance increases on filters and maps at the cost of flexibility and more upfront design. Experimental results are promising, definitely not production ready though.

▲

g-b-r 3 hours ago | parent | next [-]

No, SQL is what it is today because it was crappy in the beginning and no one managed to replace it.

It was only a partial implementation of the relational model, we could have been so much better had it not become the standard

	▲	YuechenLi 2 hours ago \| parent [-]
		The sad reality is that having something that works, even if badly, is better than having a theoretically elegant architecture that is not implemented. See JS or Linux vs Hurd for other examples. Ask yourself this question, supposedly somebody made the full implementation of the relationship model into a database engine tomorrow, will you use it yourself, and can you convince your company to use it in place of SQL? Again, I wish this wasn't the case, but I'm not sure if there is anything we can do about the adoption problem.

▲

calvinmorrison 3 hours ago | parent | prev [-]

doesnt meant the syntax isnt a pile of dog farts

▲

YuechenLi 2 hours ago | parent | next [-]

I agree, yeah, SQL syntax is awful. But the easier solution is what pretty much what backend has converged on, have something in your backend programming language that lowers to SQL so you never have to write any raw SQL at all except as a low-level escape hatch, so that in most instances SQL just becomes an IR that nobody really needs to think about in normal application code.

▲

drfloyd51 3 hours ago | parent | prev [-]

Are we really this devolved as coders? We can’t handle different syntaxes? We need LLMs to write queries? What the heck is going on with our industry?

Old man rant off.

	▲	3eb7988a1663 2 hours ago \| parent \| next [-]
		I don't take it as too-much-syntax in the brain[0], but all of the problems bad syntax causes. We could still be writing code in assembly, but we have found that different languages make things easier or safer to construct. I can trivially handle having to repeatedly bounce to the top-then-to-the-bottom of a query I am writing because I want to change the group-by or sorting order, but that is annoying friction. Since the language does not compose well, you need to keep most of the query in your head and cannot build it up piecemeal as easily as something like PRQL (https://prql-lang.org/) [0] Although, it would be incredible if I could write timestamp formatting without having to look up the bespoke vendor incantation every time I switch dialects.
	▲	g-b-r 3 hours ago \| parent \| prev [-]
		Syntax affects readability and writing speed a lot