igalklebanov

here's a good write up on the type-safety advantages https://github.com/thetutlage/meta/discussions/8

As far as query building goes, `kysely` is more in-depth, type-safe, expressive, 1:1 and doesn't require importing as many things.

`kysely-ctl` doesn't generate migrations for you, and `kysely` not being an ORM, doesn't provide declarative schema design.

Hey

DISCLAIMER: I'm co-leading the org/project.

We recently broke 6M downloads per week on NPM, and became 3rd after `drizzle-orm` and `@prisma/client`.

If you haven't tried it yet, it's a query builder, not an ORM. You don't outsource your SQL to someone else. It's type-safe, like.. it's super important to us. You can use it with ORMs - e.g. Prisma, mikro-orm, zenstack, etc. Allows you to compose some complex stuff but keep it maintainable af.

If you have. Great seeing ya'll here.

0.29 was a real nice release, with lots of goodies. Can't wait for 0.30, gonna be super fun.

can you share your personal documentation story? what did you not find? what was painful?

it depends on the database. the major ones support savepoints. postgres included. https://www.postgresql.org/docs/current/sql-savepoint.html https://dev.mysql.com/doc/refman/8.4/en/savepoint.html https://learn.microsoft.com/en-us/sql/t-sql/language-element... https://sqlite.org/lang_savepoint.html

in kysely, the dialect you're using has to implement the new optional savepoint-specific methods for it to work.

thoughts? requests? issues?

<3

JOOQ is cool!

What do you mean by "better type safety"?

Kysely's ecosystem has 2 codegen libraries:

kysely-codegen introspects the database directly.

prisma-kysely generates types based on Prisma schemas.

Looks cool!

Kysely was inspired by Knex, but took a more predictable route instead of providing generic APIs that produce different SQL for different dialects. We believe that dialect "lock-in" should never be a real concern because migrating from let's say, MySQL to PostgreSQL is extremely rare in the real world.

postgres.js is dope! I'm maintaining a Kysely community dialect for it. https://github.com/igalklebanov/kysely-postgres-js

<3 from Kysely.

Would love to have a discussion about your use case in our discord. We're constantly thinking about improving that part of our API as it's at the heart of many things.

Huge shoutout to our community, bloggers and youtubers!

https://github.com/kysely-org/awesome-kysely

<3 from Kysely. kysely-codegen is dope!

I'd suggest you try them both, and pick what you like better or what feels safer to bet on for your project.

I know some of our users use both, zapatos for codegen and kysely for querying.

It was also requested in prisma-kysely recently.

Might be a good idea to check kysely-codegen's issues section and open an issue if it wasn't requested yet.

Hey :wave:

Igal from Kysely here (I did not create it, Sami did).

Our site is a constant WIP. We've recently revamped "Getting Started" and added a lot of examples. If you can't find something there, check the API docs site or JS docs in your IDE - everything is documented.

We respond quite fast on discord if you've got any questions.

Feel free to ask me questions here too. :)

We love Knex, and are inspired by it. Sadly its not type-safe and reaching type-safety would require a rewrite.

We care a lot about our TypeScript compilation performance and Developer eXperience in general.

v0.25 introduced internal changes that doubled the possible complexity of CTEs, joins and conditional selects.

We also provide helper methods that "reset" the stack in a type-safe way.

Kysely has community projects that offer Database interface auto-generation.

kysely-codegen can introspect all core dialects. prisma-kysely can generate straight from Prisma schemas.

We recommend using these in production apps. You could verify everything is aligned in your CICD workflows.

> which supports automatic type-safety for complex joins, CTEs, subselects etc. I evaluated Kysely as well but found the sql feature set coverage of ts-sql-query better at the time.

Kysely also provides "automatic type-safety for complex joins, CTEs, subselects etc.".

Gotta love how toxic some open-source maintainers are, bashing other libraries while self-promoting.

<3 from Kysely. kysely-codegen is really dope!

<3 from Kysely. prisma-kysely is dope!

<3 from Kysely.

Have you read this recipe? https://kysely.dev/docs/recipes/relations

Kysely is not an ORM, its a query builder with strong emphasis on type-safety and 1:1* mapping ("What You See Is What You Get") to SQL.

Projects writing raw SQL eventually end up implementing their own query building functionality. Which adds another thing to maintain and understand - that's also lacking in features and is not as type-safe.

Just use a well adopted query builder.

> Personally I like both projects, as I hope I made clear in the OP

<3

You did, but it generally sounded like Kysely doesn't have a bunch of things, when in fact it does.

A more balanced comment would've suggested both projects have X, but I like Y's implementation better.

So I jumped in, to inform and give my 2 cents. :)

> I sense that there's some history and strife here that I'm not clued into as an outsider.

There's none of that really. :)

Kysely is just a query builder. Its human nature to always look for ORMs.

> It's also - in terms of performance - super fast

Kysely is also super fast. Your bottleneck will always be database requests. If you're chasing every milli, why node.js?

> the extra database drivers being core and developed as part of the main project.

Kysely's dialects are dead simple to implement on your own. As evident by all the 3rd party dialects being open-sourced and all the comments from people using Kysely in production with stuff like cockroachdb, mariadb, clickhouse and such.

Its unhealthy to maintain niche database knowledge in the core. We just don't have the time (FYI we do this for fun, not trying to catch all the sponsors and get VC funded) to play around with all of these technologies, and stay up-to-date with changes.

Both Sami and I have submitted pull requests in 3rd party dialect repositories in the past. I maintain a few dialects on my own.

> It supports prepared statements, which is awesome.

In connection pooling scenarios Kysely was mainly built for, prepared statements are arguably "not that great". In FaaS, a burst of requests might make your database work extra hard, as each new lambda instance comes with brand new connection/s.

> I prefer the way that it lets us write parts of queries, and compose them - like you import expressions like "and" and "eq" and you can write and(eq(users.id, 'x'), eq(users.name, 'Tom')) and you can actually stringify that to the SQL it generates. Or you can do a custom bit of SQL and use the names of table columns in that, like `COUNT(${users.name})`. I can't say scientifically that this is superior, and it's almost a little weird, but I've really found it a nice way to compose and debug queries.

This has been part of Kysely for a while now, and is only getting stronger with new `ExpressionBuilder` capabilities. The fun part is, you don't have to import anything, and are not coupled to your migration code.

You can use D1 with Kysely (the typesafe sql query builder) via the kysely-d1 3rd party dialect.

https://github.com/kysely-org/kysely

https://github.com/aidenwallis/kysely-d1