Supabase: try a schema change before bringing it to production

Give an application a backend it can read and write

Supabase builds application backend capabilities around Postgres: store business data, access it through APIs, and combine it with authentication, file storage and functions. It serves booking, publishing and business applications, rather than only presenting reports.

Suppose you maintain a photography studio’s booking website and want to add a session-duration field. Editing the production database directly would expose people using the old form to an untested rule. This article focuses on branches: try a structural change in another environment before deciding how to bring it into the production project.

Schema means rules such as tables, columns and constraints. Data means the existing booking records. Copying the schema does not necessarily copy customers’ bookings.

Establish access, then create an isolated environment

Imagine adding a duration to a photography booking. Distinguish schema from data first: columns and constraints are structure; existing bookings are records. The dashboard guide explains that an Owner or Administrator must enable dashboard branching without GitHub on a new project. Developers can then create, update and delete preview branches.

Create a branch through the branch selector and confirm the editing target. The branching overview explains that branches have separate instances and credentials, and exclude production data and storage objects by default. Include data requires the PITR add-on—point-in-time database recovery—and additional resources. Controlled test records may be enough to check a field rule.

Test the schema and application together

1. Connect the test app. Use the branch's own connection details and API access keys. A page can look like a test while its requests still reach production.
2. Change the schema. Add duration through SQL Editor or Table Editor and decide how missing values, defaults and constraints should work.
3. Use meaningful records. Test more than a complete new booking. Check how an old record with no duration passes through the change.
4. Check old and new clients. A new form being able to write is not enough: define what old forms should be able to submit and read. These are suggested acceptance checks, not automatic coverage of every business condition.

A separate environment gives changes a place to be tried. Successfully creating a table in an empty database is still different from showing that the existing business can move to it.

Review the migration before bringing changes into production

The branching path without Git connects creation, editing, generated differences and merging. A migration is a set of operations that changes the database schema from one state to another. Read the schema changes in the merge request, resolve conflicts and then confirm their application. Merging carries schema changes; it does not copy everything in the preview environment over production.

The difference tool pg-delta is still marked alpha, an early testing stage, so treat generated output as material for review. Adding a required field, removing a constraint and changing a default have different consequences for old records and code. Completing this process means the change has been tried in a branch and the team knows which structural changes will reach production, not simply that someone clicked Merge.

Keep the environment visible throughout editing

The dashboard branch selector determines which environment SQL and table editing affect; external programs use that branch’s own connection details. For the studio, “add a booking column” looks like the same operation, but its consequences differ between preview and production.

The useful design choice is to make the environment an ongoing context that people can confirm at every edit, rather than a setting selected once at creation. Separate credentials also distinguish application connections. Teams should display the environment name in their own test applications so that a normal-looking page is not mistaken for preview evidence.

Turn a direct edit into a reviewable migration

Editing a table’s structure and adding fields is straightforward, but the team needs to know what will change. A diff turns interaction into discussable schema changes: adding a column, removing a constraint and changing a default have different consequences.

The valuable question before confirmation is how old records and old code will pass through the change. Showing the diff before asking for confirmation leaves an opportunity to catch accidental deletion and missing migration work.

Fit the trial entry point to existing work

Starting a branch trial without first setting up Git integration lowers the entry cost for people who manage schema through the dashboard. Teams already reviewing migrations in code can continue using the Git path.

The lesson is to make trying a branch easier while retaining clear steps to review changes and confirm production updates. Convenience should help people enter the right environment and see the changes, rather than make confirmation disappear.