Hacker News Reader

Comment by ryanrasti | Hacker News Reader

I'm working on Typegres, a new data layer for the modern stack (TypeScript + PostgreSQL).

My take is that for years, ORMs have hidden the power of PostgreSQL behind generic, database-agnostic abstractions. This made sense in 2010, but now it's a bottleneck.

Typegres rejects this. It's a "translator, not an abstraction," designed to express the full power of PostgreSQL (all statements, built-in functions, etc.) in a type-safe TypeScript API.

The latest killer feature my take of "object-relational mapping done right": class-based models with methods that are actually composable SQL expressions. This lets you extend your tables with expressive logic and fully-composable relations.

It's easier to show than tell. Take a look: https://typegres.com/play

View on HN

Interesting! have u taken a look at safeql? https://safeql.dev/

I'm personally not a fan of query builders for SQL. it's already a defined language, why are we trying to move away from queries? On top of that SafeQL is only a dev dependency, there's no abstraction. it gets ran through any query client you want

Thanks for the great points and link to SafeQL! I'm a big fan of its approach to bringing type safety to raw SQL strings. For static queries, it's a fantastic solution.

My take is that while "Just use SQL" is healthy pushback against heavy ORMs, a good query builder solves two fundamental problems that raw SQL can't in the application context:

1. Dynamic composition: A query builder is the macro system that SQL is missing. The moment you need to build a query programatically (e.g., conditional filters or joins) you're left with messy/unsafe string concatenation

2. Handling Relations (and other common patterns): Using raw SQL, a complex query with JOINs returns a flat list of rows that now becomes the application's job to properly denormalize. It greatly reduces cognitive load to think in terms of relations, not just join conditions.

Again, showing is stronger than telling. To illustrate, I'd urge you to go through the first couple of examples in the playground and think about how you'd express them (e.g., the composability of the "example1" query) in something like SafeQL: https://typegres.com/play/

Neat idea. Would you say that biggest difference from something like Kysely is the focus on extracting common calculated SELECT targets into methods that can easily be accessed when querying? Or perhaps it's more thorough with providing TS versions of all the SQL syntax available? The list of reference fields/methods in your docs is certainly massive.

Thanks! That's a great question.

First off, I'm a huge fan of Kysely and it's a massive source of inspiration for Typegres.

You've nailed the two big differences:

* Architected for Business Logic: The primary innovation is the class-based model. This is all about co-locating your business logic (like calculated fields and relations) directly with your data model. The cool part is that these methods aren't just for SELECT; they're composable SQL expressions you can use anywhere: in a WHERE, an ORDER BY, etc. The goal is to create a single, type-safe source of truth for your logic that compiles directly to SQL.

* PostgreSQL-Native: The other fundamental difference is the focus on going deep on a single database rather than being database-agnostic. That massive list of functions you saw is a core feature, designed to provide exhaustive, type-safe, and autocomplete-friendly coverage for the entire PostgreSQL feature set. The philosophy is to stop forcing developers to reinvent database logic in their application code.

Philosophically, it's a shift from composing type-safe SQL strings (like Kysely, which is brilliant for its WYSIWYG approach) to composing SQL expressions as if they were first-class TypeScript objects.

Cool, that makes sense. Thanks for the explanation

Very cool!

Thanks, glad you think so!

Reply on news.ycombinator.com