What you can export from Supabase Cloud, and what you cannot
If a renewal, a price change, a residency requirement or lock-in is pushing you to leave Supabase Cloud, the answer to your export question is yes for the core data: the Postgres database and the Storage files can both be taken out with documented tools. The catch is that a standard daily backup is not a full copy of your project. Your Storage objects are not in the database backup, and daily backups do not keep passwords for custom roles, so those must be reset after any restore. Treat the export as two jobs, a database dump and a file copy, and plan a separate step for credentials.
For the database, the Supabase CLI db dump command produces logical dumps, and Supabase's backup guidance recommends that projects, including free plan projects, export regularly and keep off-site copies. For Storage, each project exposes an S3-compatible endpoint, and access keys are generated on the project's S3 Configuration page. Supabase's documentation shows rclone copying objects out over that endpoint. Before you rely on either path, confirm with the Supabase documentation for your plan that your project's size, object count and any Auth or Edge Function configuration are covered, because the dump is only the data layer. Functions, auth provider settings, JWT keys and domains need their own inventory.
The gaps are where planning matters most. Point-in-time recovery and managed backups stay with the hosted service, so the recovery window you have on Supabase Cloud does not travel with the export. Deleting a project permanently removes its associated data, including backups stored in S3, so keep a verified copy before any deletion or plan downgrade. Ask Supabase or check your plan terms for any retention or notice rules that apply to your account. Then run a test restore of the dump and a test copy of the files into a scratch environment before you cancel anything.
Which data types export, by method and format
This table compares the three things you can take out of a Supabase Cloud project: database schema and data, Storage objects, and project configuration. Read each row for the method, the format you get, the access you need, and the limits the documentation supports. The main takeaway is that a single export does not cover everything, and the configuration you must record by hand is the part most often missed.
| Data type | Method and format | Access needed and limits |
|---|---|---|
| Database schema and data | Supabase CLI db dump, producing SQL output that can be restored with psql | Database connection with sufficient role privileges. Supabase's backups docs say daily backups omit passwords for custom roles, so reset them after a restore. |
| Database roles | Dumped with the CLI as part of the database export, as documented in the migration guide | Confirm with current CLI options whether roles are included in your chosen dump mode. Custom role passwords must be set again. |
| Storage objects | Copied through the S3-compatible endpoint at the project reference URL using rclone | Access keys from the project's S3 Configuration page. Database backups do not contain Storage files, so this copy is separate. |
| Storage metadata | Stored in the database, so it comes out with the database dump | Restoring metadata without the matching object copy leaves records pointing at missing files. Export both together. |
| Auth users and password hashes | Included in the database export when it covers the auth schema, as described in Supabase's self-hosting restore guide | Confirm with the current documentation how hashes and sessions are handled before relying on this for user migration. |
| Project configuration | Recorded manually: JWT settings, auth provider settings, Edge Functions code, custom domains and API keys | Not covered by the database dump or the Storage copy. Ask your team to document each item from the project settings before any deletion. |
| Backups held by Supabase | Not exportable as files through the CLI or Storage endpoint; backups are removed when the project is deleted | Keep your own off-site dump and Storage copies before deleting a project, because Supabase permanently removes associated data and backups. |
What daily backups and the platform leave out
A Supabase Cloud database backup is not a full export of the project. Storage files, custom role passwords and hosted-only features sit outside it, so each gap needs its own copy, reset plan or written record before you rely on the export.
Storage objects sit outside database backups
Daily database backups hold only the metadata about files uploaded through the Storage API, not the files themselves. Copy the objects separately with rclone over the project's S3-compatible endpoint, using access keys from the S3 Configuration page. Check the copy by comparing object counts and sizes against the metadata in the database dump, and keep the copy off-site with the database dump.
Custom role passwords must be reset
Supabase's backups documentation says daily backups do not store passwords for custom roles. After you restore into a new environment, every custom role needs a new password, and the applications and services that connect with those roles need the new values. Plan the reset as a step in the restore runbook, record who owns each role, and store the new passwords in your secrets manager rather than in migration scripts.
Hosted-only features have no export
Managed backups, point-in-time recovery, branching, ETL and the Management API run on the Supabase platform and cannot be dumped. The self-hosting docs list them as unavailable when you self-host, so an export gives you data and schema but not the recovery behavior. Ask which of these features your team actually uses and decide how each one will be replaced or dropped.
Project settings and secrets
A dump does not capture dashboard configuration, the JWT secret and anon and service keys, auth provider credentials, SMTP settings, Edge Function code outside the database or custom domains. Build a written inventory of these settings before the export and record where each value lives. Generate new secrets for the target rather than copying the hosted ones, since the self-hosting guide provides scripts for that purpose.
Deleted projects take their backups with them
When a Supabase project is deleted, Supabase permanently removes all associated data, including any backups stored in S3, according to its backups documentation. A deletion therefore removes your only recovery path if no copy exists elsewhere. Before you delete or downgrade a project, confirm that you hold a verified dump, the Storage copy and the settings inventory, and keep them in storage you control.
Free plan backups need your own schedule
Supabase's backups documentation recommends that free plan projects regularly export data with the Supabase CLI db dump command and keep off-site backups. Nothing in the hosted plan replaces that routine for you. Schedule the dump, store each file with a timestamp, and test a restore on a separate instance so you know the export works before you need it.
How to run a complete export in order
This sequence takes a Supabase Cloud project from an agreed write window to a verified, off-site copy of its database, Storage files and configuration, with each step closed by a check you can record.
Agree a write window with application owners
Before any dump runs, the project owner and application teams agree when writes to the database and Storage will pause, and who can declare the window open or closed. Supabase's backup documentation does not give you a consistent snapshot of a project that is still taking writes, so the window is what makes the copies match each other. Record the start time, the expected end time and the named contact in the change ticket. The step is done when every team that writes to the project has acknowledged the window in writing.
Take a logical dump with the Supabase CLI
Using the Supabase CLI, run the
db dumpcommand against the project's connection string to produce logical dumps of the schema and data. Supabase's backups documentation recommends this approach for projects that want their own regular exports, so use it as the base copy rather than relying on the platform's daily backups. Keep the roles, schema and data dumps as separate files so each can be restored on its own. The step closes when the files exist, are non-empty, and their sizes and timestamps match the window you recorded.Copy Storage objects through the S3 endpoint
Database dumps do not include files stored through the Storage API, because the database only holds metadata about them. Generate access keys on the project's S3 Configuration page, then use rclone against the project's S3-compatible Storage endpoint to copy every bucket to local or off-site storage. Keep the access keys scoped to this task and revoke them at the end. Verify the copy by comparing object counts and checksums per bucket against the source listing, and record any object that failed to transfer so it can be retried.
Record auth, JWT, role and function settings
Some configuration does not live in the database dump, so capture it separately. Note the JWT settings and key identifiers, the auth provider configuration, redirect URLs and custom domains, the list of custom database roles, and every Edge Function's source and environment variable names. Supabase's backup documentation says daily backups do not store passwords for custom roles, so plan to reset those passwords after a restore and record which roles need them. Store this inventory with the dumps. The step is done when a second engineer has reviewed the inventory against the project dashboard and found nothing missing.
Compare row counts and checksums across the export
Before any copy leaves the source environment, compare the export with the live project. Count rows for every table in the dumped schemas, and compare those counts with the same query run inside the window. Compare the Storage object counts and checksums with the listing from step three, and check that the auth user count in the export matches the dashboard. Save the query output and checksum file next to the dumps. Any difference means the window was not respected or a copy failed, and the export is not complete until the difference is explained.
Store copies off-site and restrict access
Move the dumps, Storage copies, the configuration inventory and the verification records to storage outside the Supabase project, in a location your organization controls. Encrypt the archives and limit read access to the people named in the change ticket. Supabase removes backups when a project is deleted, so the off-site copy is the only copy you keep if the project is later closed. Confirm the transfer by listing the destination and matching checksums, and record the location in your backup register.
Test a restore in a separate environment
Restore the roles, schema and data dumps into a clean, separate PostgreSQL environment, and copy Storage objects into a test bucket. Reset the custom role passwords from your inventory, then repeat the row count and checksum comparisons from the verification step. Check that a sample of files opens and that a test login works. The export is only proven once this restore matches the source, so record the environment, the date and the result. If the test fails, correct the process and repeat the export inside a new write window before deleting anything.
How to verify an export before you rely on it
A dump file on its own is not proof that you can recover anything. Treat every export as unverified until you have restored it into a scratch Postgres database and compared the result with the source project. Run the restore on a separate machine so that a failed or partial import cannot touch anything live, and keep the dump, the Storage copy and the restore log together so that someone else can repeat the test.
Compare counts and structure, not just file size. Confirm that the schema objects match, that row counts for your largest and most business-critical tables agree with the source, and that roles and extensions are present where your application expects them. For Storage, compare object counts per bucket and check a sample of files against checksums taken from the source, since the database only holds metadata and a successful database restore says nothing about the files. Supabase's backups documentation notes that daily backups do not keep passwords for custom roles, so plan to reset those and record the change.
Test sign-in as well. Pick a set of test accounts, reset their passwords as part of the restore procedure, and confirm that each one can sign in and reach the data it should see. If the target is self-hosted Supabase, the restore path itself becomes part of the evidence, so rehearse it end to end with the same versions you plan to run. Supabase's Restore a platform project to self-hosted guide documents that path, and it is the document to check your procedure against before you need it.
What to plan before renewal or termination
Exporting from Supabase Cloud is easiest when it happens before any billing or deletion deadline, not after. The cards below cover the timing, access, retention and contract decisions that determine whether your copies are complete when the project goes away.
Start the export before the billing cycle closes
Schedule the first full dump well before your renewal or downgrade date, so any gaps show up while the project is still fully running. Run the Supabase CLI db dump command, then check row counts and schema objects against the live project. Plan a second, delta export close to the cutover date, since data written after the first dump will not be in it.
Keep the project running for final copies
Do not pause or delete the project until every export has been verified off-site. Storage objects are not part of the database backup, so they need their own copy through the S3-compatible endpoint. Keep the project active long enough to finish both database and object copies, and confirm that your team has a restore test planned against a separate environment.
Name who holds the S3 access keys
S3 access keys are generated on the project's S3 Configuration page, and API keys belong to project settings. Decide which named people or service accounts can create, rotate and revoke these credentials during the exit, and record where they are stored. Revoke the keys once copying is complete, because keys left active on a project you are leaving become an avoidable exposure.
Confirm roles and passwords in the export
Daily backups do not store passwords for custom database roles, so those passwords must be reset after any restore. Inventory every custom role, its grants and the applications that connect with it before the exit date. Record the new credentials in your secrets manager so the target environment can be connected without guessing at values.
Check deletion and backup retention terms
When a Supabase project is deleted, Supabase permanently removes all associated data, including any backups stored in S3. Copies must therefore exist elsewhere before you press delete. Ask Supabase in writing how long backups survive after a plan ends, whether Pro, Team or Enterprise terms include any data return assistance, and what they will confirm about deletion.
Review plan terms for data return
Read the contract or plan terms for your tier, including Pro, Team and Enterprise, and note what they say about data return, export assistance, notice periods and service continuity. Pricing pages describe features but are not the same as contract terms. Bring the questions to your account contact and keep the answers with your exit records, so procurement and legal can rely on them.
Where exported data goes next
Self-hosted Supabase is the most direct destination because it runs the same open-source stack. Supabase documents a restore path from platform projects, which expects the roles, schema and data exported with the Supabase CLI, restored into a self-hosted Postgres database with psql, followed by Storage objects copied over S3 and reconfiguration of JWT keys, auth providers, Edge Functions and domains. The Docker Compose stack is published in the supabase/supabase repository under Apache-2.0 and bundles Studio, Auth, PostgREST, Realtime, Storage and Edge Runtime, among other services.
- Single project per Studio: Self-hosted Studio runs one project, so consolidating several Supabase Cloud projects means running several stacks.
- No managed backups or PITR: Self-hosted Supabase does not include managed backups or point-in-time recovery, so you need your own dump schedule and tested restores.
- Community support: The self-hosting docs describe community support through GitHub Discussions, GitHub Issues, Discord and Reddit, with enterprises directed to Supabase's Growth Team.
- Upgrade discipline: Each Docker configuration release pins specific upstream service versions, and some releases require a database backup before updating.
- Hosted-only features: Branching, the Management API and ETL are not available when self-hosting, so review any dependency on them before cutover.
Confirm the Postgres version, Storage configuration and secrets handling in your own environment before you restore production data.
Appwrite is the destination when you want a different data model and a broader backend, not a like-for-like Postgres stack. Appwrite's Migrations feature imports projects from Supabase, which covers users, databases and files. Rows move into Appwrite collections, so Postgres-specific logic, views, triggers and row-level policies need to be rewritten. Functions are not moved, and you rebuild them on Appwrite's function runtime.
- Users and password hashes: Appwrite's Users API accepts a range of imported hash types, but Supabase's password hashes must match one of them, or users will need a reset. Confirm this against the export you actually take.
- Files: Storage objects come from the Supabase Storage S3-compatible endpoint, so export them first and confirm the file count and checksums after import.
- Rows: Expect partial fidelity for relational structure, so test queries and permissions against the target schema.
- Hosting choice: You run the target Appwrite self-hosted or use Appwrite Cloud, which changes who operates backups.
- Version pinning: Appwrite releases frequently, so pin the version you migrate to and record it in your runbook.
Run a trial migration on a copy of the export and compare user counts, file counts and permissions before you plan cutover.
An archive you own suits compliance retention when the data must remain available after the Supabase Cloud project is deleted, but you do not yet have a new application home. Supabase's backups documentation states that deleting a project permanently removes its data, including backups stored in S3, so the archive must exist before deletion. Logical dumps from the Supabase CLI and Storage files copied with rclone are the two parts to keep, and both should be stored under your own retention controls.
- Dump format: Store the Supabase CLI dump with its generation date and project reference, so you can match it to a retention record later.
- Storage copies: Copy objects with their paths and metadata intact, since the database holds only metadata about them.
- Custom role passwords: Daily backups do not store custom role passwords, so record how they will be reset when restoring.
- Off-site copy: Supabase's backups documentation recommends keeping off-site backups, so store the archive in a second location.
- Access and encryption: The archive contains personal data, so define who can read it and how it is encrypted at rest.
Before you delete a project, confirm with your compliance lead which retention period and format apply, and test a restore from the archive.
Questions teams ask before exporting Supabase data
How much effort does a full Supabase export take?
The effort depends mainly on what the project holds, and no fixed figure is supplied here, so measure it with a test export. The main drivers are database size, the number of Storage objects, how many custom roles and auth providers the project uses, and how much data leaves the platform, since egress on Supabase Cloud is billed by usage. A logical dump of the database is usually the quick part. Copying Storage files and reconfiguring roles, JWT keys and auth settings take more time, especially when the object count is high. Ask your team to export a staging copy first and record how long each step takes.
Can our team export Supabase data without outside help?
A competent team with database and command-line experience can run the export, but it needs a few specific skills. Someone must be comfortable with the Supabase CLI db dump command, Postgres roles and psql restores, and rclone for copying Storage objects over the S3-compatible endpoint. Someone also needs to own the secrets that come out of the export, including S3 access keys and any custom role passwords. The Supabase backups documentation explains what a dump includes, so read it before the first run. Teams without these skills often pair a database engineer with a platform owner for the cutover.
How long does the export work take from start to finish?
No fixed duration is supplied for this work, so the timeline should come from a measured test export rather than an estimate. Plan the timeline around four measured parts: the dump, the Storage copy, the restore into your environment, and the checks that confirm row counts, files and logins match. Add time for resetting custom role passwords after the restore, which the backups documentation says daily backups do not cover. Your schedule also depends on how often the data changes, because a final sync is needed before cutover. Ask any partner for a written scope and timeline before work starts.
What access and change window does the export need from us?
The export needs read access to the source project, the ability to generate S3 access keys on the project's S3 Configuration page, and a database connection string for the dump. You also need a destination environment with enough disk for the dump and Storage files. Plan a change window for the final export so writes stop or are captured before the last sync, otherwise rows written after the dump will be missing. Name one owner for every secret involved, including database passwords, S3 keys and JWT material, and rotate them once the move completes.
Should free plan projects export their data regularly?
Yes. The Supabase backups documentation recommends that free plan projects regularly export their data with the Supabase CLI db dump command and keep off-site backups. Because the free plan does not give you managed point-in-time recovery, your own copies are the main recovery path. Store exports outside the project, encrypt them, and test a restore on a separate instance so you know the files work. Remember that database backups exclude Storage files, so copy those objects on the same schedule.
What happens to our data and backups when a Supabase project is deleted?
When a Supabase project is deleted, Supabase permanently removes all associated data, including any backups stored in S3, according to its backups documentation. This means a deletion cannot be undone from the platform side. Before deleting a project, confirm that you hold a verified dump, a complete Storage copy and any configuration you need, such as auth settings and function code. Keep these copies under your own retention policy and record where each one lives, so a deletion request does not remove the only copy of regulated records.
When should we bring in a partner for the export?
Bring in a partner when the export touches regulated data, many projects, or a tight cutover window that your team cannot staff. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares the evidence your compliance assessors need. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not issue audit reports or certifications, which independent auditors and certification bodies provide.
How DeployOpen scopes and runs a Supabase data export
DeployOpen plans and runs the export of a Supabase Cloud project as a fixed-scope engagement, with the scope agreed in writing before work starts. The work covers the logical database dump, Storage objects, the gaps daily backups leave out, and the handover of verified copies into your own infrastructure.
How we scope
- Inventory which projects, schemas, Storage buckets and custom roles the export must cover.
- Record where copies must land, including the infrastructure and any residency constraints you set.
- Agree in writing how the project will be paused or deleted and who approves that step.
- Confirm which backups you already hold and which files or metadata they do not include.
How we build
- Run the database dump with the Supabase CLI and keep the output in a controlled location.
- Copy Storage objects through the project's S3-compatible endpoint using access keys you issue.
- Record custom role passwords separately, since daily backups do not store them and must be reset after a restore.
- Test a restore into a separate environment so the export is verified before any deletion.
How we hand over
- Deliver the dump files, object copies and checksums with a written inventory of what was exported.
- Document each step, the tools and versions used, and the reset steps for custom role passwords.
- Walk your team through the restore procedure and the retention of copies you hold off-site.
- Provide a deletion checklist so you know which data and backups Supabase removes when a project is deleted.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
- Re-run the export and restore test on a schedule you agree, to confirm copies stay usable.
- Review the export procedure when Supabase CLI or Storage tooling changes, and document the impact.
- Ask us to confirm the written scope and quote before the export begins, since no fixed price list is published.
