Live data from Hacker News

Show HN: Bun-sqlgen – Type-safe raw SQL for Bun, no ORM

github.com

31–40 of 44 posts

Re: Show HN: Bun-sqlgen – Type-safe raw SQL for Bun, no ORM

#31
post #5
post #3

Can you make it work/ does it work with Porsager-Postgres in modnes which buns Postgres client is «based on»?

I think with some tweaks to the TS parser that goes and looks for the sql statements it's doable. How are you solving the problem right now?

Not solved as far as I know. Most libraries don’t work well with the template syntax in porsagers Postgres

Re: Show HN: Bun-sqlgen – Type-safe raw SQL for Bun, no ORM

#32

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. [1] https://sqlc.dev/

Also SQLDelight for Kotlin: https://sqldelight.github.io/sqldelight/

Re: Show HN: Bun-sqlgen – Type-safe raw SQL for Bun, no ORM

#35

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.

Microsoft has been doing this for a long time: https://learn.microsoft.com/en-us/dotnet/csharp/linq/

We can do way better then LINQ in an extendable language.

Re: Show HN: Bun-sqlgen – Type-safe raw SQL for Bun, no ORM

#36
post #34

Kysely rules

Kysely is really cool, but I don't like that you are not writing SQL directly

You can use sql`query` anywhere you like combined with query builder syntax (or not) when you want to write raw sql and maintain type inference.

Re: Show HN: Bun-sqlgen – Type-safe raw SQL for Bun, no ORM

#37
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.

github: https://github.com/iterate/sqlfu

Re: Show HN: Bun-sqlgen – Type-safe raw SQL for Bun, no ORM

#38
post #6

Nice project, thanks! I was looking for something like that for quite a while. 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?

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)

Re: Show HN: Bun-sqlgen – Type-safe raw SQL for Bun, no ORM

#39
post #37

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. github: https://github.com/iterate/sqlfu

Really cool! I see you don't discover the SQL in the code right?

Re: Show HN: Bun-sqlgen – Type-safe raw SQL for Bun, no ORM

#40

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. [1] https://sqlc.dev/

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.

Post reply on HN