tsql VS pgtyped

We use in prod variant of no 1. [0]. Why? Because:

* it's extremely lightweight (built on pure, functional combinators)

* it allows us to use more complex patterns ie. convention where every json field ends with Json which is automatically parsed; which, unlike datatype alone, allows us to create composable query to fetch arbitrarily nested graphs and promoting single [$] key ie. to return list of emails as `string[]` not `{ email: string }[]` with `select email as [$] from Users` etc.

* has convenience combinators for things like constructing where clauses from monodb like queries

* all usual queries like CRUD, exists etc. and some more complex ie. insertIgnore, merge1n etc has convenient api

We resort to runtime type assertions [1] which works well for this and all other i/o; runtime type assertions are necessary for cases when your running service is incorrectly attached to old or future remote schema (there are other protections against it but still happens).

[0] https://github.com/appliedblockchain/tsql

[1] https://github.com/appliedblockchain/assert-combinators

Exactly. I'm happy with tsql [0] - template based, with safe sanitation, helper renderers/combinators, used in production for several years, would recommend this approach.

[0] https://github.com/appliedblockchain/tsql

Personally I prefer functional combinators like interfaces [0]. Js/ts have tagged templates which enhances those type of interfaces a lot. It gives access to full set of functionality of underlying database, not just common denominator of all used. It allows arbitrary compositions etc.

[0] https://github.com/appliedblockchain/tsql/

There is an implementation of SQL that operates on a table shaped type, entirely at type level. For your amusement: https://github.com/codemix/ts-sql

There are a bunch of more practical takes that codegen types from your database and generate types for your queries, eg: https://github.com/adelsz/pgtyped

To me the second approach seems much more pragmatic because you don’t need to run a SQL parser in a fairly potato interpreter on every build

ORMs suck, but raw SQL embedded in your code sucks too.

This might be good time to plug my TypeScript non-ORM: https://jawj.github.io/zapatos/.

I should say I also like what I've seen of https://kysely.dev/ and https://pgtyped.dev/.

Thank you for suggestions they helped me finding what I was looking for. I will either pick kysely or https://pgtyped.dev/, but first I will do some tests. Thanks!

Cool. How does this compare to SafeQL, PgTyped, and Postgres language server ?

I would instead rely on code generation like https://github.com/adelsz/pgtyped, because the embedded type-safe SQL will never fully cover all the features of vanilla SQL, for example Common Table Expression (CTE), window functions etc.

There's pgtyped, which I believe does almost the same as sqlc

https://github.com/adelsz/pgtyped

For Postgres there is https://github.com/adelsz/pgtyped, sounds pretty much like what you describe?

Avoiding the cost of learning EDSL that many Haskell DB libraries provide, I found out that only postgresql-typed and postgresql-simple allow to write only raw SQL queries easily. As I extensively use pgtyped for production Node.js application, I am thinking about using postgresql-typed. While I could find many resources for postgresql-simple, the same cannot be said try for postgresql-typed.

I would highly recommend trying out pgTyped if you want typesafe queries with postgres. It's fantastic!