Members and roles: share a database by email

A database is shared by naming people. You invite an email address, choose a role, and from then on that person opens the same tables, the same views, the same live data — with exactly the rights the role carries. There are three roles: owner, editor, viewer. There is no workspace above them: membership belongs to one database at a time.

Invite someone

1. Click the database's name in the top bar and choose Share… — or the 3-dot menu beside the table tabs, which opens the same dialog.
2. In the row at the bottom, type the address into Invite by email.
3. Pick Editor or Viewer — ownership is never sent by link; you promote someone from the member list after they've joined.
4. Click Invite.

They get one email with one link. As the email itself says, the link works once, for the next 7 days. Opening it proves control of the invited inbox — the same trust a magic link carries — so it signs the recipient straight in, creates the account if the address never had one, and lands them in the shared database. No password is set at any point, because there are no passwords.

Until the link is used, the invitation sits in the modal under Invited, not yet accepted, with its expiry date and an × to revoke it — revoking kills the emailed link immediately. Inviting an address that's already a member doesn't send anything; it changes their role in place, and the modal says so.

The three roles, honestly

Owner can do everything, and is alone in the removals that reach beyond their own work: managing members, deleting any record regardless of who made it, deleting tables, and archiving or deleting the database itself. A database always keeps at least one owner — the last one can't be demoted or removed, and the modal disables those controls rather than letting you try.

Editor builds. Editors create and edit records — any record's cells, not only their own — press buttons, import files, and change structure: add tables, rename them, add, reconfigure and delete fields. They manage views, webhooks, forms and public view links. Two lines they can't cross: an editor deletes, restores or purges only records they created themselves (the server refuses the rest, and says so), and the container-level removals — a whole table, the database, the member list — are owner-only. Note the asymmetry, stated plainly: an editor may delete a field, which takes that column's data with it, but not your record. Structure is editor territory; records are guarded per creator.

Viewer opens everything and changes nothing. Viewers see every table, every view, the member list, and can export the whole database — reading was never the thing being rationed. They can't edit a cell, press a button, or reconfigure a view. Two surfaces are absent for them rather than read-only: webhooks and forms, including a webhook's delivery log. Both are the wiring a database is built with rather than the data it holds, so both belong to the people who build it. On the published plans, viewers are free at any number; only editors will ever be billed (pricing).

The full grid of who-can-what is in what roles can do.

Per database, not per workspace

Membership is scoped to a single database. Being an editor on Sakkara Plants says nothing about any other database, and inviting someone here shows them nothing else you own. If the same team works across three databases, they're invited three times — deliberate, if occasionally repetitive: the blast radius of an invitation is always exactly one database.

Enforced at the server, on every door

Roles are not a matter of which buttons render. Every read and write — from the grid, the record panel, the import wizard, and every raw API call — passes the same server-side check. A viewer's PATCH to a record answers 403 with "Viewers can't change records."; an editor's attempt to delete someone else's record answers 403 and names the records it refused; a non-member asking for the database at all gets not_found, the same answer a nonexistent id gets, so probing ids confirms nothing.

The same is true of API keys: a key acts as its account, with that account's role in each database — there is no separate "API access" to grant or forget.

Members can also be managed over the API — GET and POST on https://tabladb.com/api/databases/:id/members and …/invitations — with the same rules: any member may read the list, only an owner may change it. The shapes are in the API reference.

The questions people ask

Can I share one table, or one view, instead of the whole database? Membership is all-or-nothing per database. For read-only access to one view's slice, a public view link is the door you want — sharing a view is the decision in full. Per-field and per-record permissions are on the wishlist, not in the product.

What happens to someone's records when I remove them? Nothing. Removal takes access, never data — their records keep their creator stamp, and re-adding the same address later restores the same rights.

Is there a limit on members? No cap on members or viewers. Invitation sends are capped at 20 per hour per sender, because each one is a real email.