Posted by b-man 12/18/2025
I’ve been heads-down on publishing a JavaScript full-stack metaframework before the end of the year. However, in the past two weeks I’ve been goaded by Claude Code to extract and publish a separate database client because my vision includes Django-style admin/forms. The idea is to use Zod to define tables, and then use raw SQL fragments with JavaScript template tags. The library adds a tiny bit of magic for the annoying parts of SQL like normalizing join objects, taking care of SELECT clauses and validating writes.
I’m only using it internally right now, but I think this approach is promising. Zod is fantastic for this use-case, and I’m sad I’ve only just discovered it.
IMO for machine-to-machine talk we should not be using a long text that needs to be parsed carefully and securely on the other side, but rather a structured structure that's easy to de-serialize (like AST packed into a protobuf, but for SQL). So that any invalid SQL parameters like "1;DELETE FROM users;--" would just fail to parse.
It may be called ABI, although it may be textual as well (like json), not necessarily binary (like protobuf).
PostgreSQL already supports binary wire protocol, but I never seen it's being used, instead people prefer sending raw SQL strings designed for humans even from applications.
And subling commenters say that all you need is raw SQL and results mapping to your code. Which I did for a while, but found that mapping is a lot of copy-pasta with minor diffs, a burden to maintain. So it's easier to use a thin library like JOOQ for mapping, or use only the mapper part of a bigger ORM framework like Django/Hibernate.
And my argument is that it's easier to map to/from a concise strongly-typed ABI/API structs instead of one raw SQL string with its structure designed for human reading/writing, like SELECT before FROM. There are such ABI-s, but they are DBMS-specific, while SQL is less so.
Also it makes an extra round-trip to server to prepare the query.
I understand that's the convention according to the IEEE and Wikipedia [1], but the name itself - Structured Query Language - reveals that its purpose is limited by design. It's a computer language [2] for sure, but why programming?
[1] https://en.wikipedia.org/wiki/List_of_programming_languages
https://www.reddit.com/r/SQL/comments/81barp/i_implemented_a...
Btw this runs in sqlite, you can try it yourself if you are interested.
Source: I was thinking of creating a programming language paradigm like sqlite/smalltalk once where resumed execution/criu like possibilities were built in. Let me know if someone knows something like this too. I kinda gave up on the project but I knew that there was this one language which supported this paradigm but it was very complicated to understand and had a lot of other first time paradigm like the code itself / the ast tree is sort of like a database itself but so the tangential goes.
Also, even within the standard itself, it allows for declarative programming.
select 1+1; -- Result: 2
That's the key difference.
Last year I read about some database researcher who implemented AoC in pretty standard SQL.
The advice to learn SQL is because it's everywhere. Now it has inertia, and a better way of doing things has an uphill battle. In 1980-s somebody compared working with SQL to drinking data through a straw, comparing to swimming in data with APL. We had a recent article comparing modern SSD delays and RAM sizes to those which defined architectures of SQL systems of recent decades - we can perhaps reengineer our databases better for modern opportunities. But all these approaches have to deal with SQL as an entrenched technology. Probably a task for a company of a Google class.
That in itself is fine, of course. Less fine is the author's thoughtless assumption that their readers are all learning about it too.