Migrating from Supabase

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 production: I’ve published a doc on Maturity Models[0]. Hopefully this makes it clear that developers should be using Migrations once their project is live (not using the Dashboard to modify their database live). It also highlights the options for managing dev/local environments. This is just a start. We’re building Preview Databases into the native workflow so that developers don’t need to think about this.

2. Designing for Supabase: Our goal is to make all of Postgres easy, not obligatory. I’ve added a paragraph[1] in the first page in our Docs highlighting that it’s not always a good idea to go all-in on Postgres. We’ll add examples to our docs with “traditional” approaches like Node + Supabase, Rails + Supabase, etc. There are a lot of companies using this approach already, but our docs are overly focused on “the Supabase way” of doing things. There shouldn’t be a reason to switch from Supabase to any other Postgres provider if you want “plain Postgres”.

3. That said, we also want to continue making “all of Postgres” easy to use. We’re committed to building an amazing CLI experience. Like any tech, we’re going to need a few iterations. W’re building tooling for debugging and observability. We have index advisors coming[2]. We recently added Open Telemetry to Logflare[3] and added logging for local development[4]. We’re making platform usage incredibly clear[5]. We aim to make your database indestructible - we care about resilience as much as experience and we’ll make sure we highlight that in future product announcements.

I’ll finish with something that I think we did well: migrating away from Supabase was easy for Val Town, because it’s just Postgres. This is one of our core principles, “everything is portable” (https://supabase.com/docs/guides/getting-started/architectur...). Portability forces us compete on experience. We aim to be the best Postgres hosting service in the world, and we’ll continue to focus on that goal even if we’re not there yet.

[0] Maturity models: https://supabase.com/docs/guides/platform/maturity-model

[1] Choose your comfort level: https://supabase.com/docs/guides/getting-started/architectur...

[2] Index advisor: https://database.dev/olirice/index_advisor

[3] Open Telemetry: https://github.com/Logflare/logflare/pull/1466

[4] Local logging: https://supabase.com/blog/supabase-logs-self-hosted

[5] Usage: https://twitter.com/kiwicopple/status/1658683758718124032?s=...

I also had the same experience with Supabase.

Even though it looks like a great product initially, it has a lot or errors and bugs when you are trying to actually build something more robust than a toy app.

Local development is a massive pain with random bugs.

The response time of the database also varies all over the place.

But the most important problem that we faced, was having so much of application logic in the database.

Row level security is their "foundational piece", but there is a reason why we moved away from database functions and application logic in database over a decade ago: that stuff in unmaintainable.

There is also really poor support and at the end of the day, the whole platform felt like a hack.

I think now, for most apps with up to 500_000 users (with 10_000 concurrent realtime connections) PocketBase is the best PaaS out there having tested a bunch of them.

A single deployable binary which PocketBase provides is a breath of fresh air.

Anything more than that, just directly being on top of bare metal or AWS / GCP is much better.

Personally, I had a really easy time getting Supabase to work locally. However, we use `dbmate` to manage our migrations instead of built-in Supabase migrations.

Also curious to hear from others on this:

> After a bit of sleuthing, it ended up that Supabase was taking a database backup that took the database fully offline every night, at midnight.

This seems like a terrible design decision if true. Why not just backup via physical or logical replication?

And totally hear the issues here with database resizing and vacuuming and other operations. That stuff is a big pain when it breaks.

How do people on HN like Row Level Security? Is it a better way to handle multi-tenant in a cloud SaaS app vs `WHERE` clauses in SQL? Worse? Nicer in theory but less maintainable in practice?

fwiw, Prisma has a guide on how to do RLS with it's client. While the original issue[0] remains open they have example code[1] with the client using client extensions[2]. I was going to try it out and see how it felt.

[0]: https://github.com/prisma/prisma/issues/12735

[1]: https://github.com/prisma/prisma-client-extensions/blob/main...

[2]: https://www.prisma.io/docs/concepts/components/prisma-client...

The documentation section here applies to so many products I've battled in the past.

> The command supabase db remote commit is documented as "Commit Remote Changes As A New Migration". The command supabase functions new is documented as "Create A New Function Locally." The documentation page is beautiful, but the words in it just aren't finished.

Great documentation is such a force multiplier for a product. It's so worthwhile investing in this.

Don't make your most dedicated users (the ones who get as far as consulting your documentation) guess how to use your thing!

I 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 provide a great way to handle migrations and RLS, that’d be the biggest improvement to most people’s workflows, I’d bet.

I really wish I could just define my scheme, tables, functions, triggers, policies etc as typescript, then have migrations generated from that.

Echo all the words from the author here, and kudos for being transparent.

I’ve faced exactly the same problems building my new product. But, on the other hand, Supabase was incredibly easy to setup, and meant I could worry about infrastructure later.

Pros and cons like with everything, and always wise to understand the flaws of the tech you’re using.

The local development & database migration story is Supabase's biggest weakness. I hate having to do migrations live in prod. The admin dashboard is just so much better than any alternative Postgres tooling that it's been worth using despite that. Takes care of the stuff I'd normally be sweating over when writing migrations like nullable fields / FK constraints / JSON formatting for default fields. Would be great if Supabase allowed for a "speculative migration" in its UX where it spit out a file you could use locally to test beforehand.

A mid way could be self-hosting Supabase, whether you use more or less Supabase features.

I know self-hosting might be challenging, specially getting a production-ready Postgres backend for it.

That's why at StackGres we have built a Runbook [1] and companion blog post [2] to help you run Supabase on Kubernetes. All required components are fully open source, so you are more than welcome to try it and give feedback if you are looking into this alternative.

[1]: https://stackgres.io/doc/latest/runbooks/supabase-stackgres/

[2]: https://stackgres.io/blog/running-supabase-on-top-of-stackgr...

update: edit

Nice read. I run 5-6 projects on Supabase currently. I have also run into the local development / migration obstacles. It's otherwise been pretty great for our needs

Interesting statement here:

"We rewrote our data layer to treat the database as a simple persistence layer rather than an application. We eliminated all the triggers, stored procedures, and row-level security rules. That logic lives in the application now."

Reminds me of the article and discussion here[0] over whether to put logic in the database or not and to what degree.

[0] https://news.ycombinator.com/item?id=35643432 "Use Databases Without Putting Domain Logic in Them"

Great read. Similar to my experience with Hasura. Migrations we’re better there but the row level security was a nightmare. Went to just a custom node backend with prisma and it’s a dream. No more writing tons of json rules and multiple views just to not query the email field.

Seems like these types of services are good for basic large scale crud applications, probably why you have Hasura pivoting to enterprise.

The quote at the end of going back the future is exactly how I felt. Will never use a Hasura/Supabase/etc again. Just makes things more difficult.

Having worked on a Baas type offering, this is all very familiar. Over the years, I've come to believe the approach of trying define a service layer with these magic abstractions is fundamentally flawed and will always lead to the problems in this article: poor performance, poor local development experience, no transparency in to what is going on under the hood. They are great for fast proof of concepts, but not sustainable, long term product development.

> 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 cheaper, and possibly simpler, options than Render?

Supabase is also great for auth. Did you reimplement auth yourself or switch to another auth service or framework?

Wait, so unknown hyped tech X didn't work out and you went back to stuff that has been around for 30 years?

I'm shocked.

I have just begun playing with Supabase and have a habit of running `brew upgrade` several times per week. It bugs me that the Supabase CLI is updated every single time I run `brew upgrade`. I suspect that if I were to run `brew upgrade` twice a day, it would probably still update every single time. It makes me feel like I'm trying to swing a bat around, except it's made of water.

> Local development was tough

> Unfortunately, we just couldn’t get it to work

Every time I read one of these migration stories, I find myself waiting with baited breath for the part the team couldn't achieve. After finding it, the remainder of the story becomes difficult to read.

It isn't necessarily the team's fault, the developer experience clearly has room for improvement. Props to Val Town for being so honest, it is difficult to do.

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.

Honestly, I want to like Supabase but a lot of this resonates with me even for a fairly small project. I also ended up with 3 user tables due to RLS limitations: auth users, public user profile info, and private user info (e.g. Stripe customer IDs). PostgREST's limitations also had me going back to an API server architecture because I definitely didn't want to write logic in database functions.

The only reason I haven't migrated yet is because I'd have to rewrite the data layer to use Prisma/Drizzle instead of Supabase's PostgREST client, and considering that this is a side project, the problems aren't quite big enough to justify that.

Real-world "things we ran into" stories like this are super helpful when choosing a service or technology.

Unfortunately, I have a similar experience with Firebase, where I wish I would have known that:

* Don't like the text of your Firebase Auth SMS verification message that we send on your behalf -> tough luck

* Your app name is longer than 15 characters? We are not going to include that hash in your Firebase Auth SMS message that is required by Android to perform an automatic login.

* Global Firebase Auth SMS pricing does not work you economically? Welcome to implement the whole thing yourself anyways.

* Dealing with development environments is flakey, as Firebase's emulators work 98% similar to production, but you will regularly hit things that are different.

* You can't completely automate environment creation/tear down, as not everything is covered by Terraform or Google's own APIs, so you will end up doing manual things in their admin interface.

* Real-time subscriptions in Firestore end up not being worth the tight schema coupling between client and server, as you can't control when the updates fire and you end up with a lot more unintended side effects than what this technology benefits you.

So after a year of workarounds you finally end up deeply understanding the trade-offs involved in Firebase and make the decision that its downsides exceed its out of the box benefits. :(

Wondering if the supabase CEO or any customers here can discuss scale. What “size” applications are doing really well on supabase? Are there any customers with TBs (or more) of data? What sort of performance are they achieving? Any customers with previous experience at a larger scale that are now using supabase and similar or larger scale, how are things going? What’s the average development team size of customers?

I mean i get that using such a service will somewhat speed up the initial “time to release”, but i still dont understand why i would use such a layer on top of a normal DB instead of just using a programming framework with an ORM or even a direct DB connection.

After some time you just run into limitations and have to maneuver the around weird stuff that somehow the platform has imposed on you, things that just wont happen if you just use the vanilla DB.

The passage in the article about the DB going offline during a backup every day at midnight is just insane to be honest.

Also these services typically cost much more than just self hosting a DB.

And why the hell would i ever put any amount of substantial business logic in the DB itself? Yes there are maybe speed benefits but in most cases the added burden of doing this is not necessary, compared with using actual code.

When using Supabase, I haven’t had any issues with the webui because I mainly use dbeaver to work with Postgres instead.

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

It definitely needs DB branching.

What 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?

Can someone explain a bit better what the issues are. What exactly are the issues with migration if you use an SQL script to do the migration instead of the supabase interface?

(Significantly edited after discussion)

I also had a tough time working w/ an app someone else built on Supabase. We kept bumping up against what felt like "I know feature X exists in postgres, but it's 'coming soon' in Supabase." IIRC the blocker was specific to the trigger/edge function behavior.

However after reflecting more, I don't remember enough to make a detailed case. Perhaps the issue was with our use of the product.

> The CLI manages the Supabase stack locally: Postgres, gotrue, a realtime server, the storage API, an API gateway, an image resizing proxy, a restful API for managing Postgres, the Studio web interface, an edge runtime, a logging system, and more – a total of 11 Docker containers connected together.

Can Supabase author a set of Kubernetes manifests similar to what they run in production, and perhaps distribute those?

Render.com is pricey, but very underrated.

If your business model isn’t broken by their pricing model, I really don’t know an easier/more time-efficient choice.

This echos my experience with Supabase exactly. We migrated to a similar solution for the same reasons.

The options for spinning up CRUD apps (ie, 95% of projects) are still quite miserable.

Amazed they used scp instead of rsync

I love Steve Krouse!!!