Live data from Hacker News

Migrating from Supabase

blog.val.town

131–136 of 136 posts

Re: Migrating from Supabase

#131

hey hn, supabase ceo here the Val Town team were kind enough to share this article with me before they released it. Perhaps you know from previous HN threads that we take customer feedback very seriously. Hearing feedback like this is hard. Clearly the team at Val Town wanted Supabase to be great and we didn’t meet their expectations. For me personally, that hurts. A few quick comments 1. Modifying the database in pr…

Echoing most of the comments here: Love your product! This feedback in the article isn't even a setback, just a learning opportunity that Supabase users know will only make it better. You guys/gals at Supabase are crushing it!

Re: Migrating from Supabase

#132

hey hn, supabase ceo here the Val Town team were kind enough to share this article with me before they released it. Perhaps you know from previous HN threads that we take customer feedback very seriously. Hearing feedback like this is hard. Clearly the team at Val Town wanted Supabase to be great and we didn’t meet their expectations. For me personally, that hurts. A few quick comments 1. Modifying the database in pr…

Just wanted to add I’ve been using the local development and migrations workflow and it has been fantastic. Honestly the only issue I’ve really had is how frustratingly difficult it is to change an id field from int8 to uuid if I mistakenly don’t choose the right one at first and the migrations get stuck on that and I have to resort to manual hacking. Setting up local/staging/prod with this new system seems really ea…

thanks Max, I'm also a fan of ionic. fwiw, I usually start with uuids now that they're natively supported: `id uuid primary key default gen_random_uuid()`. Changing a PK/FK type on a database definitely isn't trivial.

Re: Migrating from Supabase

#133
post #122

Earlier quoted context omitted.

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

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.

Re: Migrating from Supabase

#134
post #8

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

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.

Re: Migrating from Supabase

#135
post #8

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

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 co…

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.

Re: Migrating from Supabase

#136
post #133

Earlier quoted context omitted.

> Personally I like both projects, as I hope I made clear in the OP 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…

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.

Post reply on HN