What each role can do: owner, editor, viewer
Owner, editor, viewer: a matrix of who can edit, restructure, share, invite and export, plus the rule behind it. Editors build; owners remove containers.
Updated September 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 | yes | 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 | — | — |
Three footnotes the table can't hold:
- 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 containers. Anything that adds or reshapes the work — records, fields, tables, views, webhooks, imports, share links — is editor territory, and so is removing it: an editor can delete a field, column data and all, and can delete any record into its 7-day trash. What stays owner-only is the containers and the people: a whole table, 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.