3 ms·

Curious why have you decided for Drizzle over Kysely. I was recently exploring the space, and Kysely came on top as a framework with broader adoption. https:/

by gajus 3y ago

Curious why have you decided for Drizzle over Kysely. I was recently exploring the space, and Kysely came on top as a framework with broader adoption. https://npmtrends.com/drizzle-orm-vs-kysely https://npmtrends.com/drizzle-orm-vs-kysely

Akkuma 3y ago
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/drizzle-orm/src/kysely https://github.com/drizzle-team/drizzle-orm/tree/main/drizzl...
reducesuffering 3y ago
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 https://npmtrends.com/drizzle-orm-vs-kysely-vs-prisma
tmcw 3y ago
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.
- igalklebanov 3y ago
  > 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.
  - tmcw 3y ago
    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.
    - igalklebanov 3y ago
      > 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. :)
hotshoe 3y ago
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 to 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 big pro relative to kysely because 1) it takes very little effort to build a zod schema that "satisifies" the kysely type definitions and 2) I'm overriding the drizzle inferred 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. edit: while not exhaustive, I'm seeing better perf (by about 20%) using kysely compared to drizzle for identical queries on planetscale. Take this with a grain of salt since I've made no attempt to measure exhaustively, or optimize -- just using "as-is" so to speak, but thought it would be with noting and nothing to indicate to me that drizzle offers big perf improvement over kysely as has been suggested. Thanks for this post btw. Drizzle is hot and shiny right now (Theo just promoted big time), but after taking a second look at drizzle and in the process of writing up my thoughts here, it's become clear to me that I'm sticking w/ kysely.
- hotshoe 3y ago
  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.
igalklebanov 3y ago
Kysely is just a query builder. Its human nature to always look for ORMs.

by gajus 3y ago

Akkuma 3y ago

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/drizzle-orm/src/kysely https://github.com/drizzle-team/drizzle-orm/tree/main/drizzl...

reducesuffering 3y ago

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 https://npmtrends.com/drizzle-orm-vs-kysely-vs-prisma

tmcw 3y ago

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.

igalklebanov 3y ago
> 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.
- tmcw 3y ago
  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.
  - igalklebanov 3y ago
    > 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. :)

hotshoe 3y ago

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 to 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 big pro relative to kysely because 1) it takes very little effort to build a zod schema that "satisifies" the kysely type definitions and 2) I'm overriding the drizzle inferred 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. edit: while not exhaustive, I'm seeing better perf (by about 20%) using kysely compared to drizzle for identical queries on planetscale. Take this with a grain of salt since I've made no attempt to measure exhaustively, or optimize -- just using "as-is" so to speak, but thought it would be with noting and nothing to indicate to me that drizzle offers big perf improvement over kysely as has been suggested. Thanks for this post btw. Drizzle is hot and shiny right now (Theo just promoted big time), but after taking a second look at drizzle and in the process of writing up my thoughts here, it's become clear to me that I'm sticking w/ kysely.

hotshoe 3y ago
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.

igalklebanov 3y ago

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