The shape of Tabla: databases, tables, records, views

Every screen in Tabla is built from five words. Learn how they nest and nothing in the interface will surprise you again:

A database holds tables. A table holds fields and records. A view is a saved way of looking at one table.

That's the whole tree. The rest of this page is what each level is for, and one honest fact per level that saves confusion later.

Databases are the walls

A database is the unit of everything administrative: it has its own members, its own color and icon, its own timezone, and its own one-zip export. There is no workspace above it — databases stand alone, side by side, and inviting someone to one says nothing about the others.

Rule of thumb: things that belong to one working world — a shop's plants, suppliers and orders — go in one database as separate tables. Unrelated worlds get their own databases, because membership is decided at this level.

Tables are real

A table is where data actually lives, and "actually" is literal: every Tabla table is a real Postgres table, every field a real column, every record a row. Sorting and filtering run as SQL on the server, which is why a 50,000-row table stays quick and why the browser only ever holds the page of records it's showing.

Fields carry the types — currency, date, select, linked records and the rest of the catalog — and the type decides how a cell edits, how it filters, and what shape it has over the API.

Views are ways of looking, not copies

The view bar above the grid — Filter, Sort, Color, Hide fields — always belongs to the current view. A view stores those settings and nothing else. Make a second view, filter it to In stock is empty, and you have two ways of looking at one set of records: edit a cell in either and it's edited, full stop. Deleting a view deletes saved settings, never records.

Views also pick a layout: the grid, a board of cards in columns, a calendar, a gallery. Same records, stood at different angles. A view can also be shared as a read-only link with people who aren't members at all.

The record panel

Any record opens as a panel — the expand arrow on its row, or Space with the row selected — showing every field top to bottom, including ones the view hides. It's the same record, one more way of looking; arrow keys walk to the neighbors. Details in The record panel.

One API underneath

The part that pays off later: the screen is a client of the same API that serves scripts. Everything above — databases, tables, fields, records, views — exists as JSON at https://tabladb.com/api/..., addressable by the same names and ids the interface shows, at 600 requests a minute per key. Anything you can do by hand you can do from code, and webhooks announce changes going the other way. Start at The API in five minutes or the full reference.

The glossary

• Database — the top container: tables, members, color, timezone, one export.
• Table — records sharing one set of fields; a real Postgres table underneath.
• Field — a typed column; the type decides editing, filtering and API shape.
• Record — one row of a table.
• Display field — the field that stands for a record on links and cards; always the first column.
• View — a saved way of looking at a table: layout, filters, sorts, hidden fields, colors.
• Grid, board, calendar, gallery — the four view layouts.
• Record panel — one record opened as a page, every field visible.
• Select — a field with named, colored choices; Allow multiple turns one chip into several.
• Linked records — a field whose value is other records, connecting two tables.
• Member — a person invited to a database: owner, editor or viewer. Viewers read, editors change, owners administer.
• Trash — where deleted records wait, restorable, for 7 days. Deleted tables wait 7 days too, in a list of their own.
• Webhook — Tabla calling a URL of yours when records change, signed and logged.
• API key — a script's credential to the same API the screen uses.