For years, I've felt stuck between two unsatisfying options for talking to my database: use a traditional ORM that forces you to learn its quirks instead of Postgres itself, or write raw SQL strings and sacrifice type safety and composability.
ORMs discourage you from using the database's powerful native features, forcing you to pull data into the backend to transform it. Raw SQL is powerful but error-prone, and dynamic queries quickly become a tangled mess of string concatenation.
That frustration led me to build Typegres, my take on a new kind of query builder with a simple philosophy: minimal abstraction, maximum surface area.
Instead of hiding SQL, Typegres embraces it. It code-generates a type-safe TypeScript method for every one of Postgres's 3000+ built-in functions and operators. This approach has a huge benefit for iterating faster: since everything is a method, you get full discoverability via autocomplete. The ultimate vision is that Typegres not only helps you write safe queries, but actually helps you learn Postgres as you type.
Some of the things I'm most excited about:
* Full(er) Postgres Coverage: If you can do it in Postgres, you can do it in Typegres, with type-safety. This includes first-class support for advanced features like set-returning functions (e.g., `jsonb_each`).
* Composable & Type-Safe: Build complex queries from smaller, reusable parts—including subqueries—while maintaining complete type safety from start to finish.
* Ergonomic Operator Syntax: SQL operators like `+`, `=`, or `>` are just methods, allowing for natural chaining with auto-complete: (e.g., `.where(u => u.age['>='](21))`)
* Compile-Time Safety: The type system understands SQL rules. For example, it will show a TypeScript error if you try to select a non-aggregated column in a `groupBy` clause.
The coolest part is the in-browser playground, which is powered by Sam Willis's incredible PGlite project. You can try out the full library with zero setup.
A quick note on its status: this is an early developer preview. My main goal today is to see if this philosophy resonates with other developers. The core type-safety is robust, but there's many edge cases to still cover and it's not yet ready for production use. Following the project on GitHub is the best way to stay updated on the journey to 1.0.
Starting with this level of fidelity to Postgres opens the door to some pretty exciting future features— the tl;dr is that I'm optimistic this route can make significant headway into tackling the object-relational impedance mismatch (see the github README for more). Because Typegres understands the database so deeply, it can create healthier, more powerful abstractions.
I'd love to hear all your feedback in the comments. Thank you!
ryanrasti•7mo ago
For years, I've felt stuck between two unsatisfying options for talking to my database: use a traditional ORM that forces you to learn its quirks instead of Postgres itself, or write raw SQL strings and sacrifice type safety and composability.
ORMs discourage you from using the database's powerful native features, forcing you to pull data into the backend to transform it. Raw SQL is powerful but error-prone, and dynamic queries quickly become a tangled mess of string concatenation.
That frustration led me to build Typegres, my take on a new kind of query builder with a simple philosophy: minimal abstraction, maximum surface area.
Instead of hiding SQL, Typegres embraces it. It code-generates a type-safe TypeScript method for every one of Postgres's 3000+ built-in functions and operators. This approach has a huge benefit for iterating faster: since everything is a method, you get full discoverability via autocomplete. The ultimate vision is that Typegres not only helps you write safe queries, but actually helps you learn Postgres as you type.
Some of the things I'm most excited about:
* Full(er) Postgres Coverage: If you can do it in Postgres, you can do it in Typegres, with type-safety. This includes first-class support for advanced features like set-returning functions (e.g., `jsonb_each`).
* Composable & Type-Safe: Build complex queries from smaller, reusable parts—including subqueries—while maintaining complete type safety from start to finish.
* Ergonomic Operator Syntax: SQL operators like `+`, `=`, or `>` are just methods, allowing for natural chaining with auto-complete: (e.g., `.where(u => u.age['>='](21))`)
* Compile-Time Safety: The type system understands SQL rules. For example, it will show a TypeScript error if you try to select a non-aggregated column in a `groupBy` clause.
The coolest part is the in-browser playground, which is powered by Sam Willis's incredible PGlite project. You can try out the full library with zero setup.
A quick note on its status: this is an early developer preview. My main goal today is to see if this philosophy resonates with other developers. The core type-safety is robust, but there's many edge cases to still cover and it's not yet ready for production use. Following the project on GitHub is the best way to stay updated on the journey to 1.0.
Starting with this level of fidelity to Postgres opens the door to some pretty exciting future features— the tl;dr is that I'm optimistic this route can make significant headway into tackling the object-relational impedance mismatch (see the github README for more). Because Typegres understands the database so deeply, it can create healthier, more powerful abstractions.
I'd love to hear all your feedback in the comments. Thank you!
Playground: https://typegres.com/play
GitHub: https://github.com/ryanrasti/typegres