Supabase Clone Environments
Clone Supabase production data, without personal information, to a development environmentâ
We're massive fans of Supabase here at Snaplet, but as a Supabase user, youâll know the pain and manual configuration in setting up multiple environments on Supabase, and populating each of those with data. Snaplet makes populating your multiple development environments with data, and keeping that data consistent across those environments, incredibly simple. This is rooted in a philosophy we believe in here at Snaplet: Environment parity.
"Environment parity" is a term introduced by "The 12 Factor App Methodology" that instructed developers to keep our environments as similar as possible so that we could have the confidence that if it âworked on my machine,â it would work in production:
If your development, testing, and production environments differ, even in ways you might think donât matter, then you lose the ability to accurately predict how your code change is going to behave in production. This confidence in the code heading to production is essential for the kind of continuous delivery, rapid deployment that allows applications and their development teams to thrive in the cloud. â Kevin Hoffman
Environment parity sounds like a dream come true. In this guide, weâre going to tell you exactly how to do that with your data in Supabase! End-to-end, it shouldnât take more than 15 minutes, and doing so will allow you to code against an accurate development environment that you can periodically sync with production. Chef's kiss!
You can follow along in the video below as our founder, Peter Pistorius takes you through the entire process, or refer to the written guide below.
Things you'll need before you begin:â
- A production Supabase project's connection string: These can be found in Supabase via
Organization > Project > Database > Connection Pooling > Connection string
- A development Supabase project's connection string: Same steps as above, but a different project/environment
- A read-only role in Production (recommended):
To create a read-only role across all schemas you can checkout our docs. Note that you'll need to run the commands using
psql
locally (psql <connection-string>
), not using the SQL Editor in Supabase's UI.
Step 1: Connect your data sourceâ
The first thing youâll want to do is navigate to https://www.snaplet.dev/ and sign up for a new account (itâs free). Once you have successfully signed up for a new account, youâll begin the onboarding process...
Youâll then want to enter the credentials of your production Supabase project. Find the "Connection string" in Supabase via Organization > Project > Settings > Database > Connection string
(At the bottom of the page.)
Remember that the password is the same password you used when creating the Supabase project.
Youâll then have to confirm providing Snaplet access to your database. Snaplet will prompt you to only provide read-only
access to your database. We have a guide in our documentation on how to go about this and you can check that out here.
Note that whatever connection string you provide here will be that of your
Data Source
â essentially the production database in a real-life scenario
Step 2: Transform your dataâ
Here, you are going to want to exclude any schemas that you do not require. You are able to exclude an entire schema by click on the drop-down at the top, selecting the schema you would like to exclude and clicking âExclude schemaâ. Alternatively, you can select a given schema and exclude only specific tables from that particular schema. Exclude any non-required table data (such as logs) and extensions and view your columns.
At this point, Snaplet will automatically detect any columns that have Personally Identifiable Information (PII) and mark them in purple. If there are any additional columns that hold data you would like to anonymise, you can click on the respective column name and provide a replacement value for the data in that column. Once you are happy and satisfied, you can click on Review and Save
and proceed to the dashboard.
Step 3: Create a Snapshotâ
Next youâll want to create a snapshot of your production database. This is what youâre going to restore later into your data target (more on that later in the guide).
Step 4: Create a data target on Supabaseâ
Your data target is where you want Snaplet to restore the captured snapshot of your production project. This would most likely be either your staging or developer Supabase project.
If you donât already have a developer database setup on Supabase, youâll need to create a new data target by setting up a new project on Supabase. To create a new project youâll have to do the following:
- Go to app.supabase.io
- Click on ânew projectâ
- Enter your project details
- Wait for the new database to launch
Remember the password you use when creating the project. Youâll need this password to connect your database to Snaplet later.
Step 5: Install the Snaplet CLIâ
- Open your terminal and run
curl -sL https://app.snaplet.dev/get-cli/ | bash
- Run
snaplet auth
- Navigate to
https://app.snaplet.dev/access-token/cli
to get your access token - Paste your access token in the terminal
Step 6: Restore to the data targetâ
You're now ready to restore your production snapshot into your Supabase development project.
- Navigate to your project directory
- Run
snaplet config setup
â you will be prompted to enter your database credentials. These are the database credentials of your data target. This could be your staging or development database. Note that you need to be using thepostgres
user for your development environment. This will already be the case if you copied the connection string fromOrganization > Project > Database > Connection Pooling > Connection string
for your development project. - Run
snaplet project setup
- you will be presented a list of options, these are databases that are connected to your Snaplet account - Select a data source from the list
- Run
snaplet snapshot restore
A note about warningsâ
When running snaplet snapshot restore
, you may see warnings such as:
Could not drop schema "auth", Snaplet will try to truncate all tables and related objects as a fallback: error: must be owner of schema auth
[Schema] Warning: type "aal_level" already exists, statement: "CREATE TYPE auth.aal_level AS ENUM (...
Supabase databases include a few schemas that aren't owned by the postgres
user, for example: auth
, graphql
, realtime
and storage
. Snaplet will still try capture data for tables under these schemas if it has permissions to read data from them. The warnings just mean that when Snaplet tried restore these schemas, it was not able to drop first the schemas that were there prior to the restore (since the user is not the owner of these), and consequently that it was not able to create any structure for them (since that structure still exists). Snaplet will still make sure to clear all data for tables in these schemas, and to restore data for each of these tables to what is in the snapshot. In other words, these warnings do not mean that the restore failed, but rather to show you what Snaplet tried to do.
If you aren't actually needing the data for some of these schemas, you can stop these warnings by excluding the schema from the captured snapshots. You can read more on how to do this over here in our docs:
All done!â
As a Supabase user, you can see how this solves an issue we all typically experience when attempting to create multiple development environments and populating each of those environments with data that you can work with. With Snaplet, this process is simplified down to creating the respective Supabase projects, connecting the data source (The production database) to Snaplet and telling Snaplet where to restore that data (staging and development databases).
If you want to learn more about Snaplet, you can explore our docs. If you have any questions, feel free to reach out on Discord .