Skip to content
Open beta — everything’s free right now, and your rate is locked when it ends.
The product

It’s all here.

Four views. Every field type, including the ones that only matter on the day you need them. Formulas, rollups, two-way links. Group-by, footer summaries, row and cell coloring. One filter grammar — the same in the grid, the API and your webhooks, and written down. Public read-only links. Undo, and a trash that holds everything for seven days. Webhooks with a delivery log you can replay. And the whole database back out in one file.

Every feature, free right now while we’re in beta. Your rate locks when the beta ends.

The Tabla grid — a Time entries table with colored activity chips, linked projects, a duration field and a currency field
The data

There’s a real database under here.

Every table you make is a real, indexed Postgres table — not records hiding inside a JSON blob with a spreadsheet painted over it. That isn’t trivia. It’s why a 50,000-row table opens in about a third of a second, why sorting stays quick as the data grows, why a filter means exactly what it says, and why the export is a boring afternoon instead of a project.

You never see any of it. That’s rather the point.

TextLong textNumberCurrencyPercentRatingDateCheckboxURLEmailPhoneSelect (single)Select (multi)AttachmentsLinked records — two-wayFormulaLookupRollup

The four in green read across your links — formulas, lookups, rollups, and two-way records.

Single select to multi and back — it converts, and it tells you what it’s about to do first.

The Tabla grid scrolled to the end of a 100,000-record Time entries table
The looking

The records stay put. The view moves.

A view isn’t a copy. It’s a lens on the same records — drag something in the calendar and the grid already knows, because there’s only ever one of it. Four lenses, and as many saved views as your work needs.

A grid view of projects
The same projects on a timeline, each one a bar running from its start date to its due date
The same projects as a gallery of photo cards
The same projects as a kanban board grouped by stage in colored columns

Group, sum, color

Group by any field. Sum, average or count in the footer. Color a row — or a single cell — by whatever conditions you like. Open a record in the panel and edit it there.

Right-to-left, natively

It reads right-to-left when your data does — in the grid, every view, filters and webhooks. Arabic isn’t a setting we bolted on afterwards.

أميرة فؤاد · غرفة النيل · ٣ ليالٍ · مؤكد
A real record, reading the direction it was written.
status is confirmedANDnights > 2
In the grid

Click the filter button. Pick the field, the operator, the value. It’s the toolbar you’d expect.

In the API

The same expression, as a parameter. Same fields, same operators, same meaning.

In a webhook

The condition that decides whether it fires. Same grammar again.

One grammar, three places, and it’s documented. Learn it once.

{
  "join": "and",
  "conditions": [
    { "field": "Status", "op": "is",      "value": "Confirmed" },
    { "field": "Nights", "op": "greater", "value": 2 }
  ]
}
  • Keys are exactly field / op / value. Operators are words, not symbolsgreater, not >.
  • field takes the field id (fld_…) or the human name.
  • A single top-level join over a flat list — and "join": "or" works too. AND and OR.
The connecting

Built to be talked to.

Point a webhook at any table. Four trigger types, each one honest about transitions — not “the status is confirmed,” but “the status became confirmed.” Set the conditions with the grammar you already know. Make as many as you like; nothing counts them.

CreatedUpdatedMatches a conditionDeleted
Every fire carries the change

The before and the after.

Your platform never goes back to ask what changed — it’s already in the payload. A bulk write of fifty records doesn’t fire fifty times, and if an endpoint dies, we pause after twenty failures rather than hammering it for a week.

POST · delivered200 OK
"event": "record.updated",
"changed_field_ids": ["fld_status", "fld_balance"],
"before": { "fields": { "status": "pending", "balance": 320 } },
"after":  { "fields": { "status": "confirmed", "balance": 0 } }
SignedHMAC-SHA256
Retriedthen paused, not hammered
Loggedreplay any delivery
Never losttransactional outbox

And one API door.

Not one for reading and a different one for writing — one, with a real OpenAPI spec you can point your tooling at, and the same filter grammar you learned in the grid.

One door

OpenAPI spec

Read and write through the same documented API. No second dialect.

Room to move

600 req / min

Six hundred requests a minute on an API key. Double Airtable’s cap.

Upload a file

One call

Send an attachment to a record without a three-step dance.

Public links

Read-only

Show someone a view without an account. They see the view, not the database.

The safety

The day you paste over three hundred rows.

Every tool shows you the happy path. Here’s the other one — because that day is coming, and how a tool behaves in the ninety seconds afterwards is most of what you’ll remember about it.

Undo. And redo.

The one everybody assumes is there until it isn’t.

A trash that holds everything for seven days

Not just records; tables too. Delete the wrong thing on Friday and fix it on Monday.

Change a field’s type and it warns you first

It tells you what it’s about to do to your data, then waits.

Two people editing at once don’t clobber each other

The second save is told, not silently swallowed.

Owner, editor, viewer

Invite by magic link. Viewers are free, always.

No password to lose

There isn’t one. Sign in is a link in your inbox.

And the last safety net is the door.

One click pulls the whole database into a single zip — every table, every record, every attachment. No waiting for an email. Free, always. How that works →

Tabla — Product