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.
> 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
Y'all are saints in this space. Every other managed db provider does everything possible to make leaving as difficult as possible. Definitely gives me a lot more confidence using Supabase in the future
Appreciate this well-thought out response. As someone who has built several proof-of-concepts on Supabase (but never going far enough to test its limits), articles by Val Town here and responses like yours all work towards my analysis of the platform for future projects.
It's funny that threads like these bring up comments like "Well I use XYZ and it solves all of my problems." As if a one-time mention of a new PaaS is enough to bank on it for future projects. Although I can't lie - I do bookmark every PaaS that I see mentioned on HN.
Regardless, I'd much rather put my faith in a platform like SB that has been battle-tested in public, even if it doesn't work out perfectly every time.
Always glad to see you and the team showing up for the discussions and improving SB.
Not paradoxical at all. They're clearly interested in competing fairly instead of locking you in. That's a big advantage. They're also critically evaluating their approach. Exactly what I as a customer would want!
Let me just say that (for me) Supabase is one of the most exciting startups of the past couple years and I'm sure these issues will get ironed out eventually. I believe in your overall mission and am inspired by how much progress you all have made in just three years.
I feel like the issue with the Supabase dashboard and database modification is more one of your general approach. You put editing stuff all right up front when at best it should just be an emergency hatch, and the only place to find info on migrations is by going and looking around in the docs.
yes, I agree. We're working on ways to make the Migration system more prominent in the Dashboard. Preview Databases will help with this too.
> just be an emergency hatch
I would go as far as saying that migrations should still be used beyond the initial development. The Maturity Models linked above include 4 stages: Prototyping, Collaborating, Production, Enterprise. After "Prototyping", everything should be Migrations.
The exception is that you can use the Dashboard for local development. When you run "supabase start", you can access the Dashboard to edit your local database. From there you can run "supabase db diff" to convert your changes into a migration.
Hi, I've recently gave supabase a shot to as an alternative to firebase because I needed SQL. One thing that I've struggled with from the start is that supabase seems to ignore backends completely.
I don't want to use supabase edge functions, since I want to keep it simple with a single express backend and don't want to be vendor-locked.
Currently only a hobbyist but so far I really enjoy using Supabase and have appreciated the generous free tier. Maybe some day, if I'm lucky, I'll prioritize my projects further and pursue monetization. It would be a great personal development if I needed to graduate to the paid tier.
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!
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.
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?
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!
For me it's the opposite. You've got the CEO speaking corporate platitudes trying to defend himself in the comments by removing focus on the actual issues at hand. LLM helped summarize the issues at hand.
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=...