K

Kysely•16mo ago

Murf

I’m well versed in SQL and priority #1 is performance. Can Kysely still make sense for me?

The TLDR is, I am impressed by Kysely and it seems like a great library… but I also don’t want to use it just because it looks wonderful I am brand new to the ORM / query builder world. We are migrating a project to SQLite and my decision is coming down to raw SQL (which I am very comfortable with and is my natural inclination) vs Kysely. Here are some questions I have:

1. Could / should I use Kysely and just use the sql template literal tags which is comfortable for me given my raw SQL experience?
2. Are there performance considerations? I know with full blown ORM the answer is obviously yes but wondering with Kysely if there are many performance trade offs in comparison to writing raw sql?
3. If I use just sql template tags does that defeat most the propose of Kysely or is that still a valid use case?
4. Outside of building queries (and the obvious TS type safety that comes with it), are there other benefits that come from Kysely?

I mean this as a compliment and not a bad thing that the Kysely library looks so nice and intriguing to use that I may not “need” it but am trying to justify a reason to BUT at the same time, it’s the classic JavaScript problem of need vs want and how much value do you get from a library.

Thanks in advance!!

Solution

1. If you only use raw SQL, Kysely offers very little to no type-safety for you.
2. With other dialects, not really. With sqlite, Kysely wraps the better-sqlite synchronous API to an async API that can decrease performance. I haven't measured it, but there could be an impact.
3. Yes.
4. You can think of Kysely just as a type-safe way to write raw SQL. That's all it tries to do and that's pretty much the only benefit.

Jump to solution