What each role can do: owner, editor, viewer
The reference matrix for Tabla's three database roles — who can view, edit, delete, restructure, share and export — plus the two rules that explain every row. Checked against the code that enforces it.
Updated August 2026
Every member of a database holds one of three roles, and every operation — on screen or over the API — checks that role on the server before anything happens. This page is the matrix. How people get these roles is members and roles.
| Capability | Owner | Editor | Viewer |
|---|---|---|---|
| Open the database: every table, record and view | yes | yes | yes |
| See the member list | yes | yes | yes |
| Export the whole database as one zip | yes | yes | yes |
| Create records and edit any record's cells | yes | yes | — |
| Press buttons | yes | yes | — |
| Import spreadsheets into tables | yes | yes | — |
| Delete, restore and purge records they created | yes | yes | — |
| Delete, restore and purge anyone's records | yes | — | — |
| Change structure: create and rename tables; add, edit and delete fields | yes | yes | — |
| See and manage webhooks, including the delivery ledger | yes | yes | — |
| Build, pause and delete forms | yes | yes | — |
| Create, configure and delete views | yes | yes | — |
| Public view links: enable, disable, regenerate | yes | yes | — |
| Webhooks: create, edit, pause, test, replay deliveries | yes | yes | — |
| Invite members, change roles, remove members | yes | — | — |
| Delete a table, and restore one from its 7-day trash | yes | — | — |
| Archive or delete the database | yes | — | — |
Four footnotes the table can't hold:
- The record-delete rule is per creator, and it follows the record into the trash. An editor trashes only records they created, restores only their own, purges only their own, and their Empty trash empties only their own. A record created before roles existed, or by an API key with no member attached, belongs to nobody in particular — only an owner can delete it.
- A viewer's export carries no comments. The zip is otherwise identical, and its README stops describing the file rather than promising one that isn't there — comments are editor-and-owner everywhere else in the product, and the export doesn't quietly widen that.
- A database always keeps at least one owner. The last owner can't be demoted, removed, or invited into a lesser role; every path that would orphan the database refuses.
- Ownership never travels by invitation. Invitations carry editor or viewer. Making someone an owner is an in-app promotion by an existing owner, never a forwardable link.
The two rules worth remembering
Every row above compresses to two sentences.
Editors build; owners remove. Anything that adds or reshapes the work — records, fields, tables, views, webhooks, imports, share links — is editor territory, including removals of structure an editor made or didn't (an editor can delete a field, column data and all). What stays owner-only is destruction beyond your own contribution: other people's records, whole tables, the database, and the member list itself.
A role is a server fact, not a UI state. The grid hides buttons a role
can't use, but that's courtesy, not the mechanism. Every door — Server
Actions, the REST API, API keys — re-checks the role on
each request. A viewer's write answers 403 forbidden ("Viewers can't change
records."), and a non-member gets not_found, indistinguishable from an id
that never existed. There is no request path that trusts the client.
Viewers are always free
Reading was never the thing being rationed. During the open beta everything is free anyway; on the published plans, only editors are billed and viewers are free at any number — see pricing and free and beta.