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.
To give context, Val Town have a particularly write-heavy setup, storing a lot of json strings. The nightly backups were causing write-contention, even at their relatively small size. We didn’t detect errors because they were application-level. We should have moved them to PITR as soon as they mentioned it since the timing was so obviously coinciding with backups. We’re investigating moving everyone to PITR (including the free tier). At the very least, we’ll add more control for backups - allowing users to change the maintenance window, or possibly disabling backups completely if they are managing it themselves.
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.