Deleting: what comes back and what is gone for real

Tabla's deletes come in two shapes. Records and tables go to a 7-day trash: they leave the screen at once and come back whole if you ask within the week. Fields and databases are demolition — the real Postgres column, or every table under the database, dropped on the spot — so the ceremony is heavier and the answer to "can I get it back?" is no. This page is the map, drawn before you need it.

Records: the reversible world

Deleting a record asks nothing. It moves to a per-table trash, stays 7 days, and restores whole — attachments, links to surviving records, all of it. One deletion offers Undo for 8 seconds and answers Cmd+Z after; deleting several asks once, plainly. The chevron on the table's tab → Deleted records… is where they wait. The record trash has the details — who can restore what, the hourly sweep, Delete forever.

Cell edits aren't deletes at all: overwrite a value and undo walks it back while the tab is open.

The trash's two hard edges: Delete forever and Empty trash… are final, file bytes included. And clearing an attachment cell asks first — "This can't be undone." — because discarded file bytes don't come back.

Fields: one click of friction

Deleting a field is structural — it drops the real column and every value in it — but it confirms with a single dialog rather than the typed ritual:

Delete field "Price"? This drops the real column and all of its data. This can't be undone.

Two clauses join in when they apply: a link field's dialog adds "removes its mirror field, and drops their link connections", and when the trash holds records, "Records in the trash lose this field too" — a restored record can't bring back a column that no longer exists.

A deleted field is gone.

Tables: seven days, the same as a record

From the active tab's chevron, Delete table takes effect at once — no dialog, whether or not the table holds records. A notice at the foot of the screen says where it went, with Undo beside it for eight seconds:

Deleted "Bookings". It's under Deleted tables in the ⋮ menu for 7 days.

That is the same bargain a deleted record gets, and for the same reason: the seven days are the real safety net, so a confirmation in front of them is a second lock on a door that was never the risk. Until the week is up, columns in other tables that link here read empty. After seven days it is all gone for good, those columns included.

Only an owner can delete a table, and only an owner can bring one back.

Where a deleted table waits

The ⋮ at the end of the tab strip → Deleted tables…. Each row is a table name, how long ago it went, and Restore, newest first. That's the whole dialog: no Delete forever, no paging — the list is the tables you deleted this week, and the seven days run down on their own.

What the seven days actually hold

Nothing is dismantled when a table goes to the trash. The real Postgres table, its rows, its fields, its views and its files stay exactly as they were; what changes is that the table is no longer listed, no longer readable and no longer writable. So:

• Link columns in other tables read empty while the table is away, and fill back in on restore, holding the same records — the connections were never cut. Lookups and rollups riding those links go quiet and come back the same way.
• Forms and shared view links stop answering immediately — a visitor gets a plain not-found, never a door onto a table you just deleted. Restore switches back exactly what the delete switched off, so a form you had paused yourself stays paused.
• The table's webhooks are switched off, and switched back on by the restore.
• A new table may take the old one's name while it's away. If one has, the restored table comes back as "Bookings (restored)" and the dialog tells you so rather than leaving you with two identical tabs.
• It still counts toward your account's table and record ceilings. The rows are on disk and in tonight's backup for another week — invisible, not absent. The counts you can see, like the "N tables" on a database card, leave it out.

After seven days the hourly sweep performs the delete that was deferred: the real table, its records, its files, and the link fields pointing at it from elsewhere — mirrors included — all go, permanently.

Over the API, DELETE /api/tables/:id is the same act with the same seven days. There's no restore endpoint: the trash is there for a hand that slipped, and the dialog in the app is where the week is spent.

Databases: type the name, or archive instead

Delete database… lives in the database menu (click the name in the top bar) and always runs the typed ritual: "This deletes every table, record, view, and webhook in this database, and it cannot be undone. To keep a copy, cancel and run Export database… first." From the home page's ⋮ menu, a database with no tables skips the ritual — again, nothing to lose. Owners only, both places.

A database delete is permanent, and it takes any table sitting in the table trash with it.

One honest refusal: deleting while something is still writing — an import, usually — fails after ten seconds with "Something is still writing to this database — an import, most likely. Wait for it to finish, then delete."

Archive is the third option, and usually the right one. The home page's ⋮ menu → Archive moves the database into a collapsed "Archived databases" section, data fully intact. Unarchive brings it back exactly as it was. A finished project should be archived, not deleted — archiving costs nothing and reverses completely.

The honest table

You deleted	Comes back?	How
A record	Yes, for 7 days	Trash → Restore, or Cmd+Z right away
A record, after Delete forever / Empty trash / 7 days	No	—
A cell's value	Yes	Undo, while the tab is open
An attachment (cell cleared or file removed)	No	—
A field	No	—
A table	Yes, for 7 days	⋮ at the end of the tab strip → Deleted tables… → Restore
A table, after 7 days	No	—
A database — archived	Yes, entirely	⋮ → Unarchive
A database — deleted	No	—

Backups are the disaster plan, not the undo button

Tabla keeps nightly off-site backups of the whole service, retained 30 days, so a disaster on our side stays survivable. They are not a per-item undo: there is no button that pulls one field or one database out of a whole-system backup, and nothing above depends on one. Before big surgery — restructuring, mass deletes — take sixty seconds and export the database. The zip is yours, complete, and needs nobody's help to open.

Two side effects worth knowing: deleting a record fires its record.deleted webhook at trash time (purging fires nothing), and a table going to the trash fires nothing at all — its own webhooks are switched off in the same breath, and come back with it.