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.
> 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.
Summarizing/defining that as specifics:
> Local development: The team at Val Town found local development challenging with Supabase. All of their development initially took place in production, with everyone connected to the production database, which is not a typical practice. When Supabase introduced a toolchain for local development, the Supabase CLI, the team encountered issues such as broken Docker containers, a database migration system that couldn't handle custom roles, and missing CLI help. They were not able to maintain a local development environment for more than a day at a time because either the CLI would break, or migrations were generated incorrectly and couldn't be applied
> Documentation: Val Town found the documentation for Supabase to be incomplete, with crucial commands not adequately documented. While the documentation page was aesthetically pleasing, the actual content was lacking. For instance, the command supabase db remote commit is documented as "Commit Remote Changes As A New Migration," but the team felt that it was important to know what this command would do before running it. Similarly, the documentation for parts like the Supabase Remix integration was found to be insufficient, leading to unexpected outcomes such as a required reset of all user sessions because using it meant switching from localStorage to cookie-based authentication
> Database management: The team also experienced issues with downtime and database management. Val Town was taking a database backup that took the database offline every night, which affected their operations. It took them a week to get Supabase to stop taking these backups. Additionally, Supabase's scheme for database size, which starts small and auto-resizes as the database grows, created a problem when their system failed to resize Val Town's database, putting them in read-only mode. When the disk was 95% full, operations to reduce the size on the disk needed extra temporary space, which was not available. This situation led to a 'catch-22' scenario where attempts to reduce the size of the disk pushed it over 100% of disk utilization, causing a restart. They managed to resolve the situation by finding a table they no longer used, which freed up 5 gigabytes of storage. The Supabase web user interface also crashed when the database crashed, emphasizing the need for separate systems for administration and the thing being administrated
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
Anyways, thank you. Supabase isn't perfect but it's pretty damn good.
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...
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.
In firebase, the Admin SDK https://firebase.google.com/docs/admin/setup solves this, but seems to be missing in supabase. For example, for a simple JWT verification, I had to go to old github issues, rather than finding the answer in the docs. https://github.com/supabase/supabase/issues/491#issuecomment...
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=...