Branches and browsing

Your project has one database. What it has many of is branches — copies of that database, each with its own connection string.

The studio shows the branches, the tables on each, and the rows in each table. You can change a value in place.

Branches

A branch is a copy-on-write clone. Creating one takes about a second whatever the size of the parent, because nothing is copied: the branch points at the same data and diverges only as it is written to.

production          your database
├── staging         everything production had at 14:32, going its own way since
└── preview/pr-42

That is a different thing from an empty second database, and a more useful one. A preview environment wants production's rows as they are now, not an empty schema. A migration rehearsal wants the data that will break it.

Each branch has its own compute and its own host. The connection string for staging is not production's with a word changed — it is a different machine. Writes on one never reach the other; the copy was taken once, at the moment you made it.

You pay for what diverges, plus the compute each branch uses while it is awake. A branch nobody queries costs almost nothing, and one that has drifted a gigabyte from its parent costs that gigabyte.

Ten branches per project. Ask if you need more — it is a bound on runaway CI jobs rather than on cost.

A branch never expires on its own. The engine underneath supports branches with a time to live, and we do not use it: a branch you made to hold a copy of production before a migration is still there next week, and next month. Branches go when somebody deletes them.

Deleting a branch

Type its name to confirm. The branch and its compute go; anything written to it since the copy was taken is lost, and its parent is untouched.

Two branches cannot be deleted:

• production, which is the database itself. Deleting the project removes it, and that is reversible for 30 days.
• any branch with branches of its own — delete those first. A copy cannot outlive the thing it was copied from.

Browsing

Open a branch to see its tables: names, estimated row counts, and size. Open a table to see its rows, fifty at a time, ordered by primary key so that page two is the same page two on the next click.

It is not a replacement for a SQL client. There is no query box, no schema editor, no import. It is for the thing you actually open a client for most often: what is in this table right now, and can I fix that one wrong row.

The list says about n rows because it is Postgres's own estimate — an exact count means scanning the table, and doing that for every table to draw a list would wake the compute and hold it. Open a table and the count at the bottom is exact.

Editing a value

Click a value, change it, save. One cell, one row, one update.

A table needs a primary key to be editable. Without one there is no way to name a single row — where email = … could match four — so those tables are shown read-only rather than edited hopefully. Adding a primary key makes them editable.

Primary key columns are not editable here either. Changing a key moves a row rather than edits it, and doing that from a grid is how a foreign key ends up pointing at nothing.

An empty field means null where the column allows it, and is refused where it does not. null and an empty string are different values and the studio shows them differently.

What it means that we can see it

Everywhere else, your database is yours alone: your application connects directly, and nothing of ours is on that path. This page is the exception.

To draw a table for you, our server connects to your branch. So, plainly:

• It uses your credential, the same connection string you have. The studio can do nothing in your database that you cannot do yourself.
• It happens only while somebody has the page open. There is no background job reading your data, and nothing is copied to our side — each page is a query, and when the tab closes there is nothing left.
• Only your schemas. Postgres's own catalogs are refused rather than listed, including the one that holds role password hashes.
• There is one write, a single-cell update addressed by primary key. No statement in the studio can affect a row that was not named.
• Only owners and admins can change data. Members see the same tables and cannot edit them.

If that is not a trade you want to make, do not use this page — everything else about your database works the same either way, and nothing here is required.