You can actually integrate both as well if you really want to leverage Drizzle for schema building and migrations: https://github.com/drizzle-team/drizzle-orm/tree/main/drizzl...

You should consider the similar reasons why you chose Kysely over Prisma. Prisma has far broader adoption. https://npmtrends.com/drizzle-orm-vs-kysely-vs-prisma

Sure! I think Kysely is great too, but went with Drizzle for a few different reasons:

Kysely is a little more established than Drizzle, which I think is one of the major reason why it has broader adoption. My bet is that Drizzle is moving really fast, gaining adoption, and might catch up at some point. It's also - in terms of performance - super fast, and nicely layers on top of fast database clients.

Some of the differences that I liked about Drizzle were the extra database drivers being core and developed as part of the main project. It supports prepared statements, which is awesome. The Drizzle API also covers an impressive percentage of what you can do in raw SQL, and when there's something missing, like a special column type, it's been pretty straightforward to add.

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.

That said, Kysely is also a great project and it'd be possible to build great products with it, too. I just found the momentum, API, and philosophy of Drizzle to be pretty compelling.

> 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.

Personally I like both projects, as I hope I made clear in the OP - I sense that there's some history and strife here that I'm not clued into as an outsider.

> 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. :)

My personal problem with Kysely is that the migrations are not aligned with what I needed personally.

I would have wanted to see Kysely have the ability to generate migrations for example. I also personally prefer the approach that Drizzle takes when it comes to more adoption (in my case, CockroachDB).

Just a personal preference - the project is awesome.

Drizzle-kit, the migration part of drizzle is not open source, though they said they will open source it in future, but not at this point. Kysley is 100% open source, feature rich and more stable, again back to active development.

atlasgo io looks promising to handle migrations and is open source as well. I am currently using prisma.

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

I've been evaluating both (kysely, drizzle), and I'm leaning towards Kysely. Drizzle is the latest, but both are moving fast if you look at the git insights. I find Kysely more enjoyable and straightforward -- intellisense autocompletions work better (for me at least), and the expression builder combined w/ helper methods like jsonArrayFrom offer a lot of flexibility over how to shape the output, so you're in full control, which is one of the reasons I wanted to explore alternatives to primsa in the first place. I had actually decided on kysely, but am taking another look at drizzle because of recent support for relations added. The added support is a nice addition, but there's boilerplate one needs to write to take advantage of and, frankly, I just find it easier to get same results w/ kysely, again, w/ added flexibility (it is not trying be be an orm). Some things I really like about drizzle are not needing to generate schema and lets you map column names (e.g., created_at db col maps to createAt object name). Drizzle can also infer types from schema, but, I haven''t found this to be a bit pro relative to kysely because 1) it takes very little effort to build a zod schema that "satisifies" the kysely's type definitions and 2) I'm typically overriding the drizzle infered types anyway to get the finally runtime checks implemented (e.g., is a cuid2 of 16 len, not just is a string). I've also been using prisma-kysely, which gives me ubiquitously supported prisma tooling for handling migrations, etc.

One minor correction (sort of), just noted in docs that kysely provides a built-in camel case plugin, for transforming camel to snake case so, eg.g, createdAt to created_at in db. Not as flexible as arbitrary transform but it serves my needs perfectly.