Is Supabase Truly Production Ready?

[terehov]

We are evaluating Supabase for our next project, and so far we like it quite a bit. However, I have some concerns about whether Supabase is truly production-ready. I know it's claimed to be, but I have some doubts:

1. Backups:

   • The backups seem to only concern the database. Buckets are not backed up.
   • Files are deleted immediately, and if a database backup is restored, the entries in the storage schema no longer match the buckets.
   • There's no real way to back up the buckets either. The S3 compatibility is far from being complete and not suitable for this purpose.
   • The recommendation to bring your own storage provider is also not helpful since this functionality is also not complete.
   • How can one establish a proper backup strategy for a core feature in a production environment?

2. Row Level Permissions:

   • Supabase is built on PostgreSQL and uses Row Level Permissions, which is great.
   • However, the permissions are not included in the migrations.

3. Branching:

   • Branching does not seem to be fully implemented. It appears to set up a new database and apply the migrations and seeds.
   • Permissions are not transferred, and there's no way to promote versions.

Am I overlooking something? Is there a recommended approach to address these concerns? Any guidance or clarification would be greatly appreciated. Thank you!

[gc-ft]

Hi @terehov,

1. Backups
I totally agree with your Backups concern related to buckets. A good system for backing up storage is missing clearly. In my opinion the storage system of supabase needs to be used in connection with your own management of files, meaning you need to keep records of your files on your own on top of the storage schema, considering the storage schema in the db itself is mainly just for supabase to know what files it has in storage and to allow for RLS policies to work with files.

So if you do not want files deleted right away, simply do not use the storage system directly, instead flag files on your own end as "deleted" so you no longer show them, and use a cron or the like to flush "the bin" manually when needed. That's how I would "solve" the "files are deleted immediately" sync issue...

This of course does not solve backing up the buckets somewhere themselves for safety, however I guess replicating the files to your own S3 should not be a very hard setup using a trigger?

2. RLS
Row Level Security Policies are in migrations, not sure why you believe this is not the case? The migrations have CREATE POLICY/ lines in them. If you are missing policies from schemas that are not "public" or a schema you added manually, that is because only the schemas "extensions", "public" and any custom schema you created are placed in migrations by default. So you have to manually create migrations for other schemas as needed, usually storage and/or auth.

When you create a migration via supabase db pull it actually warns you about this:

The auth and storage schemas are excluded. Run supabase db pull --schema auth,storage again to diff them.

3. Branching
I understand why you claim permissions are not transferred if you have the issue of 2. - But I do not see how this can be the case, there must be something else going on at your end that is causing this to fail (again, unless we are talking about storage schema or such).

Branching is not meant in the way you seem to want to use it however! It is more of a "development" branching and not a "staging" logic.. Because data is not copied (just seeds), it makes little sense in my opinion to offer to "promote" the branch to production? I believe the intended purpose of this is not to have a fully working copy of the supabase instance, just a quick copy to run tests against and do some final testing before the next step.

I have been thinking about CI/CD pipeline logic with supabase the last days myself, and the best setup for me is the following:

1. Two supabase projects, one for production, one for staging.
2. Use GitHub Actions, instead of the Supabase <> Github Integration
3. Best GitHub Workflows logic for me would be:

• Any pull request opened for develop branch in git, should create a supabase branch via terraform in the staging project, to run tests and see if everything works in general. This supabase branch can be removed when the pull request is closed.
• Any push onto develop branch in git runs tests and if ok will push new migrations and all functions to supabase staging project
• Any pull request opened on main branch in git, should again create a supabase branch but this time on the production project, possibly with more complete seed data and/or other things to be tested that only make sense to test prior to production release.
• Any push onto main branch in git pushes the new migrations and functions to the supabase production project

There is a good example for Github workflows working this way here: https://github.com/supabase/supabase-action-example
This is just missing the functions part! There is an example for this in the Edge Functions Docs though: https://supabase.com/docs/guides/functions/cicd-workflow

Could be this is possible with a mix of supabase <> GitHub integration AND GitHub Actions, but considering there is terraform, I am not sure if it is really needed. The only additional benefit of using GitHub integration for branches would be the integration with Vercel if you use Vercel too.

Fabian

[dunivlorraine]

Short answer (I'll detail it later):

• the cloud version seems to be close to be production-ready
• the self-hosted one is just barely usable as a development environment

[giosueDelgado]

Can you explain better?