Coming from Airtable: a translation guide

If you know Airtable, you already know most of Tabla. Tables, fields, records and views mean the same things and behave the way your hands expect. This page is the dictionary for the rest: the words that change, the things the importer carries across, and the things that genuinely land differently.

The words

Airtable says	Tabla says
base	database
workspace	nothing — databases stand alone, and members are invited per database
table, field, record	the same three words
primary field	display field
view	view
grid view	grid
kanban view	board
calendar, gallery	calendar, gallery
form view	a form — its own tab, not a view
single select + multiple selects	one Select field, with an Allow multiple toggle
collaborator field	member field
linked records	linked records
attachments	attachments
interface	forms for intake; the API and webhooks for everything else
automation	a webhook into your automation tool — fired by a record change, or by a button on the row

The pattern: data words survive, packaging words change. A base full of tables is a database full of tables; the one renaming with an opinion in it is board, because that's what the thing is — "kanban" appears in Tabla's own menus too, so either word finds it.

The importer does the heavy lifting

You don't retype anything. Import data… → Connect an Airtable base reads a base over Airtable's own API and rebuilds it: tables, fields, records, the links between records, attachments (the actual files are fetched and stored, not hotlinked), and select choices with their colors mapped to Tabla's palette. The walkthrough, including the OAuth connection and what to check afterwards, is Airtable import.

What lands differently

Four things do not survive the trip unchanged:

• Formulas, rollups and lookups arrive as frozen values. Airtable's API returns a computed field's current value, never its formula source, so there is nothing to translate — each becomes a plain column holding what it last computed. Rebuild the live versions with Tabla's own formula, lookup and rollup fields; deciding which is which takes a minute per field, not an afternoon.
• Collaborator columns arrive as text — the names, not live people. Invite your team to the database, add a member field, and reassign.
• Views don't come across. Filters, sorts and hidden-field choices are rebuilt by hand in views — for most bases this is minutes, and a decent occasion to drop the views nobody opened since 2023. A form view is rebuilt as a form, which is a separate tab here rather than a view, and gets its own link.
• Automations and interfaces don't come across, because Airtable's API doesn't expose them and Tabla doesn't have equivalents to receive them. Tabla's answer to automations is different in shape: a webhook fires on record changes, signed and logged, into whatever tool runs your logic — n8n, Make, or your own code. Interfaces have no Tabla equivalent today; if you lean on them, know that before you move. Buttons also don't import (they're not data), though Tabla has its own button field to rebuild with.

Nothing to translate on the pricing page

The part of an Airtable migration nobody writes down is re-learning the feature matrix — which views, which permissions, which limits live on which plan. Tabla removes the exercise: every feature is on every plan, viewers are always free, and the only number that changes with money is editors. Free while in beta, per-editor after. What you build on the free plan is exactly what you'd have on a paid one.

What Tabla doesn't have

No interfaces or dashboards, no per-field or per-record permissions, no timeline or Gantt views. Some of these are on the wishlist; none of them exist today. If your base is mostly interface, Tabla replaces its data layer well; the surface you build on top is forms for intake and the API for everything else.

Start with the importer, or take the ten-minute first run with throwaway data first — the vocabulary above will have you oriented before the kettle boils.