I'm currently contracted on a greenfield Django REST framework app and if the decision had been up to me I probably would have gone with Supabase right off the bat. But honestly I'm absolutely loving Django REST framework over vanilla Postgres. It took me a while to get the hang of views and serializers and validation, etc, but now that I do it feels incredibly flexible and powerful. One thing I'm loving is how easy it has been for me to write management commands and build a comprehensive test suite, and that's one aspect of building a web app that I don't hear talked about much with Supabase.
Migrating from Supabase
111–120 of 136 posts
Re: Migrating from Supabase
#112I hadn’t touched SQL for almost 7 years, but dipped my toes back in to build a PoC using Supabase. Despite some initial pains around RLS, I’ve grown to love it. Sure, Supabase has some awkward quirks and issue, and author has some good points. But when it works like it should, it’s pretty awesome. I think of it as a powerful wrapper around solid services that make for great DX, in _most_ cases. If Supabase could prov…
> I really wish I could just define my scheme, tables, functions, triggers, policies etc as typescript, then have migrations generated from that.
I've recently been using the Django ORM, which automatically generates migrations, and it is absolutely awesome.
Re: Migrating from Supabase
#113hey 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…
Really appreciate this response. Looking at your first link, there's a link to this page which currently resolves to a 404: https://supabase.com/docs/guides/platform/docs/guides/platfo...
Re: Migrating from Supabase
#114What was most shocking to me was that it took a week to migrate 40GB. I once migrated 1TB from RDS Oracle to RDS Aurora MySQL in 6 hours. I'm not familiar with Supabase, maybe there's a lot more to the data migration process?
Supabase developer here. It shouldn't (and doesn't) take a week to migrate 40GB, I'm sure most of that time was strategizing, analyzing, and testing things. Supabase is pure Postgres running on AWS, so migrations are pretty straightforward. Things mostly depend on where you're migrating to/from, and the network latency between the source and destination. 40GB should take minutes in most cases.
Re: Migrating from Supabase
#115> we just wanted a database. ... > Render Preview Environments are amazing: they spin up an entire clone of our whole stack — frontend remix server, node api server, deno evaluation server, and now postgres database — for every pull request. So they wanted more than a database then, no? Are they saying they really just needed a DB and the other stuff was a nice bonus? If they really wanted just a DB, are there not ch…
They just want to think about it as just a database when they are in building-the-application mindset. But they want it to have lots of conveniences and features and easy management when they are in building-the-company-and-team mindset.
Re: Migrating from Supabase
#116What was most shocking to me was that it took a week to migrate 40GB. I once migrated 1TB from RDS Oracle to RDS Aurora MySQL in 6 hours. I'm not familiar with Supabase, maybe there's a lot more to the data migration process?
There were a couple of factors why it took a week:
1. We wanted to avoid downtime, so the pg dump was slowed down because it was happening alongside production use of the db
2. We abuse postgres in a couple of ways (too many large json columns) which makes it harder to export and import
3. We were moving between cloud regions and cloud providers.
4. I'm a bit of a database ops noob (part of why supabase was appealing in the first place) so I had to learn how to do all these things. Like burggraf said, a lot of that week was planning, trial and error, test runs, mistakes that would cost full days, etc.
Re: Migrating from Supabase
#117Curious 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
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 dif…
> 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.
Re: Migrating from Supabase
#118Curious 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
Kysely is just a query builder.
Its human nature to always look for ORMs.
Re: Migrating from Supabase
#119hey 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…
Hey, I’d love to try out Supabase as a backend for Flutter apps. However, the docs and scaffold code, like authentication flows, are a bit lacking for Flutter. What are the plans for improving the Flutter-related documentation and packages? Are there any good first issues on GitHub related to Supabase + Flutter?
Re: Migrating from Supabase
#120hey 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 easy. Nice work!