I write Bun.sql with raw SQL and no ORM, and the one thing I kept missing was types. You write a query, get back `any[]`, and hand-write a row type that silently drifts from the actual columns. Drizzle/Kysely fix this by moving the query into TypeScript, but then you're not really writing SQL anymore.
bun-sqlgen goes the other way. You keep writing raw SQL queries, just give each one a name.
A codegen step reads your migration `.sql` files, stands up a throwaway Postgres via PGlite (so no Docker) or SQLite, prepares every tagged query against it, and writes a `.d.ts` that maps each query name to its real result type. After that, plain `tsc` does the rest: `user.notExistingField` won't compile, and `display_name.length` gets flagged because the column is nullable.
Nullability was the annoying part. Postgres's describe doesn't hand you per-column nullability, so I infer it from the query plan plus the catalog, with manual overrides for the cases that genuinely can't be inferred. SQLite works too.
The runtime stays 100% Bun.sql, the generated file is the only artifact (commit it), and codegen is fast enough to rerun on save.
It's early (v0.1, built it for my own projects) so I'd mostly like to hear where it falls over.
have a look at https://sqlfu.dev - if you're using sqlite especially this likely has what you're looking for
(disclaimer: i made sqlfu! and it's pretty early so use with appropriate caution. there's very little to the runtime part of it though, just very thin adapters around battle-tested clients)
Those looking for a more mature solution in this space will probably enjoy SQLc [1]. It was initially developed for Go applications, but over the years it got pluggins for many other languages, including JavaScript/Typescript.
I love sqlc, but I think it's more fair to say it's an SQL code generator for Postgres and Go. Everything else is much less well-supported. You can pretty much forget about trying to use it with ClickHouse or SQLite, for example.
It's also a project that seems to be suffering a bit from maintainer burnout. Important bugs aren't being fixed and contributor PRs aren't being merged. It took months to merge support for the new "\restrict" syntax introduced in Postgres 17's SQL schema dump format, for example.
I don’t understand why no one is making SQL a first class citizen in a language, there are tons of languages out there that are extendable, how hard can it be, enough of DSL and generated type-safe application code which is a DSL in reverse order.
We built something quite similar - a full SQL framework with migrations, schema diffing, type-generation (this is the similar part I think), and named queries along with observability and more: https://sqlfu.dev
It also ships adapters for pretty much all platforms, for sqlite at least: bun, node, libsql, better-sqlite3, expo-sqlite, sqlite-wasm, etc. etc.
22 comments
[ 2.9 ms ] story [ 47.1 ms ] threadbun-sqlgen goes the other way. You keep writing raw SQL queries, just give each one a name.
A codegen step reads your migration `.sql` files, stands up a throwaway Postgres via PGlite (so no Docker) or SQLite, prepares every tagged query against it, and writes a `.d.ts` that maps each query name to its real result type. After that, plain `tsc` does the rest: `user.notExistingField` won't compile, and `display_name.length` gets flagged because the column is nullable.
Nullability was the annoying part. Postgres's describe doesn't hand you per-column nullability, so I infer it from the query plan plus the catalog, with manual overrides for the cases that genuinely can't be inferred. SQLite works too.
The runtime stays 100% Bun.sql, the generated file is the only artifact (commit it), and codegen is fast enough to rerun on save.
It's early (v0.1, built it for my own projects) so I'd mostly like to hear where it falls over.
Any chance to get it to work with Node?
Unfortunately in my opinion and experience Bun is not really suitable for production. Does it have anything special which makes this possible?
(disclaimer: i made sqlfu! and it's pretty early so use with appropriate caution. there's very little to the runtime part of it though, just very thin adapters around battle-tested clients)
https://sqlc.dev
[1] https://sqlc.dev/
It's also a project that seems to be suffering a bit from maintainer burnout. Important bugs aren't being fixed and contributor PRs aren't being merged. It took months to merge support for the new "\restrict" syntax introduced in Postgres 17's SQL schema dump format, for example.
It also ships adapters for pretty much all platforms, for sqlite at least: bun, node, libsql, better-sqlite3, expo-sqlite, sqlite-wasm, etc. etc.
github: https://github.com/iterate/sqlfu