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.