# Airtable

> The spreadsheet that is really a database: bases, fields and linked records, views, built-in automations, and Interfaces - plus the point where it stops being the right tool.


---

# Airtable

You know how to use a spreadsheet. You've also felt where it falls apart: the
file with twelve tabs, the "do not delete this column" notes, the moment two
people overwrite each other's work and you can't tell what changed. Airtable
is what you reach for when a spreadsheet has stopped being enough but a real
database feels like a step too far. It looks like a grid, so you already know
how to type into it. Underneath, it behaves like a database - and that
difference is the whole point.

This guide is for the founder running their pipeline in a Google Sheet, the
ops person tracking inventory across three tabs, the analyst who keeps a
"master list" everyone copies and breaks. You don't need to be technical.
You need to understand a handful of ideas - fields that have types, records
that link to each other, views that show the same data different ways - and
then you can build something that holds up when more than one person touches
it.

We'll go in four steps. First, why Airtable is a database wearing a
spreadsheet's clothes, and what "fields have types" and "linked records"
actually buy you. Second, the parts that make it feel like an app: links,
lookups, the different views, filtering, and automations that do work for you
while you're asleep. Third, Interfaces - turning your data into a clean
screen other people can use without seeing the messy grid - plus sharing,
permissions, and the real limits on how much data Airtable will hold. By the
end you'll know what Airtable is great at, and the exact moment it's time to
move on to something heavier.


---

# A Spreadsheet That's Really a Database

Open Airtable and the first thing you see is a grid. Rows, columns, cells.
Your hands already know what to do. That familiarity is deliberate - and it's
also the trap, because the moment you treat it like a spreadsheet, you'll
miss the parts that actually matter.

Let's get the vocabulary straight, because Airtable renames things you
already know.

- A **base** is the whole project. Think of it as one workbook - your CRM,
  your content calendar, your inventory system. Everything for that one job
  lives inside it.
- A **table** is one sheet inside the base. A base usually has several:
  Customers, Orders, Products. Each table is one kind of thing.
- A **record** is a row. One customer. One order. One product. In a database
  you'd call it a row; Airtable calls it a record, and it's worth adopting
  the word, because a record is a thing, not a line of cells.
- A **field** is a column. Name, Email, Price, Status.

So far this is a spreadsheet with fancier names. Here's where it stops being
one.

## Fields have types, and the type is the rule

In a spreadsheet, a cell holds whatever you type. You can put "$45", "forty
five", and "TBD" in the same column and the sheet won't blink. Six months
later that column is garbage and no formula trusts it.

In Airtable, every field has a **type**, and the type decides what's allowed
in. You set it once, and the field enforces it forever after.

| Field type | What it holds | Why it helps |
|---|---|---|
| Single line text | Plain text | Names, short labels |
| Number / Currency / Percent | Real numbers | Math works; no "$" mixed with words |
| Date | A real date | Sorting and "due this week" actually work |
| Single select | One choice from a list you define | No more "Done" vs "done" vs "complete" |
| Multiple select | Several choices from a list | Tags, categories |
| Checkbox | True / false | Clean yes/no |
| Email / Phone / URL | Validated contact info | Tappable, harder to mistype |
| Attachment | Files and images | The grid holds the photo, not a link to it |

The single select field is the one that converts spreadsheet skeptics. You
define the allowed options - say, `Lead`, `Negotiating`, `Won`, `Lost` - and
from then on a status field can only ever be one of those four. No typos, no
drift, no "wait, is 'Closed' the same as 'Won'?" The data stays clean because
the field won't let it get dirty.

This is the first real database idea: **structure up front, instead of
cleanup forever.** A spreadsheet lets you put anything anywhere and makes you
pay for it later. Airtable asks you to decide what a field means once, then
holds the line for you.

## Records are objects, not lines

In a spreadsheet, a row is a horizontal strip of cells. If you want to see
one customer's full story, you scroll sideways past thirty columns and lose
your place.

In Airtable, click a record and it opens as a **card** - every field for that
one customer laid out top to bottom, like a contact in your phone. You can
attach files to it, leave comments on it, see its history. The record feels
like a thing you can hold, because that's what it is. This matters more than
it sounds: when your data is records-you-open instead of rows-you-scroll, you
start thinking about your information as objects with relationships, which is
exactly the mindset a database wants.

## Linked records: the idea that changes everything

Here's the move that a flat spreadsheet cannot make.

Imagine a sheet tracking orders. Each order needs the customer's name, email,
and shipping address. In a spreadsheet, you type those into every order row.
Customer places ten orders? You've typed their address ten times. They move?
You hunt down all ten rows and pray you found them all. The same fact lives
in ten places, and ten places means ten chances to be wrong.

Airtable's answer is the **Linked record** field. You keep one Customers
table and one Orders table. On the Orders table, instead of typing the
customer's details, you add a link field that points to the right record in
the Customers table. You're not copying the customer - you're pointing at the
one true copy.

```text
Customers table
  - Acme Co   (email, address, phone - stored ONCE)

Orders table
  - Order #1001  →  linked to: Acme Co
  - Order #1002  →  linked to: Acme Co
  - Order #1003  →  linked to: Acme Co
```

Now the customer moves. You update their address in one place - the Customers
record - and every order pointing at them reflects it instantly. Nothing to
hunt down, nothing to miss. This is the principle databases are built on:
**store each fact once, and refer to it from everywhere else.**

```mermaid
graph LR
  O1[Order #1001] --> C[Acme Co]
  O2[Order #1002] --> C
  O3[Order #1003] --> C
  C --> A[One address,<br/>one email]
```

Links also go both ways automatically. Open the Acme Co record and Airtable
shows you every order linked to it, with no setup on your part. You get the
customer-to-orders view and the order-to-customer view from the same single
connection.

That's the whole leap from spreadsheet to database, in one feature. A
spreadsheet stores values. Airtable stores values *and the relationships
between them* - which customer placed which order, which task belongs to
which project, which invoice covers which line items. Once your data knows how
its pieces connect, you can do things a grid of disconnected cells never
could. Those things - pulling linked data across tables, summarizing it, and
making the whole base do work on its own - are where we go next.


---

# Links, Views & Automations

In the last phase you linked tables together - Orders point at Customers,
Tasks point at Projects. The link by itself only connects records. The next
three features are what turn that connection into something useful: pulling
information across the link, looking at your records in whatever shape fits
the job, and getting the base to act on its own.

## Lookups and rollups: borrowing data across a link

Once an Order is linked to a Customer, you often want the customer's email to
*show up on the order* - not retyped, but pulled live from the linked record.
That's a **Lookup** field. You point it at the link and say "show me the
Email from the linked Customer." It reads through the link and displays the
real value. Change the email on the Customer record and the lookup updates
everywhere it appears. You're seeing one fact in many places without
duplicating it.

A **Rollup** is the same idea, but it *summarizes* many linked records into
one number. Open a Customer and you want their total spend across all orders.
The rollup looks at every linked Order, grabs the Total field from each, and
adds them up.

| You want | Use | What it does |
|---|---|---|
| The customer's email shown on the order | Lookup | Pulls one value across the link |
| Total of all this customer's orders | Rollup (sum) | Adds a value across many links |
| How many orders this customer has | Rollup (count) | Counts the links |
| The latest order date | Rollup (max) | Picks one value from many |

Between linked records, lookups, and rollups, you can build something that
feels alive: a Customers table where each row quietly shows total spend, order
count, and last-order date - all calculated from the Orders table, all
current, none of it typed by hand. That's work a spreadsheet does with
fragile formulas you copy down a thousand rows and break by accident.
Airtable does it once, at the field level, and it stays correct.

## Views: same data, different shape

This is the feature people fall in love with. A **view** is a saved way of
looking at one table. The data underneath never changes - you're only
choosing how to see it. One table can have a dozen views, each tuned for a
different person or a different job.

- **Grid** - the spreadsheet you already know. Good default for editing.
- **Kanban** - cards in columns, grouped by a single-select field. Drag a
  deal from `Lead` to `Negotiating` and the field updates. Sales pipelines
  and task boards live here.
- **Calendar** - records placed on dates by a date field. Content calendars,
  deadlines, bookings.
- **Gallery** - big cards with images. Product catalogs, a team directory,
  anything visual.
- **Form** - a fill-in-the-blank form that creates a new record when
  submitted. Share the link and outsiders add data without ever touching
  your base. Intake requests, signups, surveys.

The win is that the *same records* power all of them at once. Your sales team
works the Kanban board. Your ops person reads the Grid. A customer submits the
Form. The calendar shows what's due. Nobody is copying data between tabs,
because there are no tabs - there's one table and many windows onto it.

## Filtering, sorting, grouping

Each view can **filter** to show only the records that matter there. A "My
open deals" view filters to `Owner = me` and `Status is not Won or Lost`. A
"Overdue" view filters to `Due date is before today`. The hidden records
still exist - they're not deleted, only out of frame for this view.

You can also **sort** (newest first), **group** (cluster all `Won` deals
together with a subtotal), and hide fields you don't care about right now. A
busy 40-field table becomes a calm 6-field view that answers one question
well. Set these up once per view and they stick.

## Automations: the base does the boring part

An **automation** is an if-this-then-that rule that runs inside your base, no
code required. You pick a **trigger** - something that happens - and one or
more **actions** - things Airtable then does.

```text
WHEN  a record's Status changes to "Won"
THEN  send an email to the account owner
AND   create a record in the Onboarding table
AND   post a message to the team Slack channel
```

Common, genuinely useful patterns:

- A form submission comes in → send the submitter a confirmation email.
- A task's due date is tomorrow → notify the assignee.
- A new record is created → fill in default values or stamp the date.
- A status flips to "Approved" → create the matching record in another table.

Triggers can be a record entering a view, a field changing, a form
submission, a scheduled time ("every Monday at 9am"), or a button someone
clicks. Actions can email, update or create records, run on a schedule, or
call out to other apps - directly to a few popular ones like Slack, and to
hundreds more through connector services such as Zapier or Make.

A plain word about limits: automations are billed by **runs**, and your
plan includes a monthly allowance. A rule that fires on every record change in
a busy base can eat through that allowance faster than you'd guess. Trigger on
the narrow thing you actually care about - a status reaching one specific
value, not "any edit to this record" - and you'll stay well inside the
budget while the base quietly does your routine work for you.

With links pulling data together, views showing it from every angle, and
automations handling the repetitive parts, you've got something that behaves
like an internal tool. The last step is giving other people a clean way to use
it without handing them the raw grid - and knowing where the whole thing
runs out of road.


---

# Interfaces, Sharing & When It Breaks

You've got a base that holds clean, linked data and does work on its own. But
the grid is still the grid - dense, editable, a little intimidating. You don't
want your sales team rearranging fields or your client poking at raw tables.
You want them to see a tidy screen that answers their question and nothing
else. That's what Interfaces are for, and that's where this last phase starts.

## Interfaces: an app on top of your data

An **Interface** is a page you design that sits on top of a base. Same data
underneath - you're building a friendlier front door to it. You drag in
elements: a chart, a list of records, a few number cards at the top, a filter
the user can change, buttons. The result looks like a small app, not a
spreadsheet, and you built it without writing code.

The key thing to hold onto: an Interface is a **view of the data, not a copy
of it.** Someone edits a record through the Interface and the base updates,
the same as if they'd typed in the grid. There's no syncing, no export, no
second source of truth. The Interface is a window; the base is the room.

Typical uses:

- A **dashboard** - charts and big-number cards so a manager sees the state
  of things at a glance, with no way to accidentally break a formula.
- A **record review screen** - pick a deal from a list, see its full detail,
  update a status, leave a comment.
- A **focused workflow** - "here are the requests assigned to you; approve or
  reject each one" - hiding every field that isn't part of that decision.

The same base can carry several Interfaces, each aimed at a different person.
The sales rep gets their pipeline. The exec gets the dashboard. The contractor
gets one screen with only their tasks. Everyone touches the same live data;
nobody sees more than they should.

## Sharing and permissions

Control over who-can-do-what works at a few levels.

| Level | Common roles | What they can do |
|---|---|---|
| Whole base | Owner / Creator | Build tables, fields, automations |
| Whole base | Editor | Change records, not the structure |
| Whole base | Commenter | Comment, not edit |
| Whole base | Read-only | Look, not touch |
| Interface | Per-user / group | See only the Interface, not the raw base |

That Interface row matters most for outsiders. You can share an Interface with
someone and they never see the underlying tables at all - they get the clean
screen and nothing behind it. For one-off external input, a **Form view**
(from the last phase) lets anyone with the link add a record without an
account. And a **shared view link** lets you send a read-only or filtered
slice of a table to someone outside your workspace.

A practical caution: collaborator-level access is what most plans charge for,
per seat. Read-only Interface and form sharing is the cheap way to let lots of
people see or submit data without paying for each of them as an editor. Reach
for that before you start buying seats for everyone who needs a peek.

## The real limits

Airtable is generous until it isn't, and the ceilings are real. The exact
numbers shift with your plan and over time, so treat these as the shape of the
limits rather than gospel - but the shape is what matters for deciding whether
Airtable fits.

- **Records per base are capped**, and the cap scales with your plan - roughly
  a few thousand on the free plan, tens of thousands on paid, into the
  hundreds of thousands on the top tiers. This is the single most important
  number. A base is not built to hold millions of rows.
- **Attachment storage** is metered too; a base full of photos and PDFs eats
  space fast.
- **Performance sags as a base grows.** Big tables with many lookups,
  rollups, and links get noticeably slower to load and edit long before you
  hit the hard record cap. Tens of thousands of heavily-linked records is
  where people start feeling the lag.
- **Automation runs** are rationed monthly, as covered earlier.

None of this is a flaw - it's the trade. Airtable spends performance and scale
to give you a friendly, no-code, multi-view tool. For most internal projects
that trade is the right one for years.

## When to graduate to a real database

Airtable stops being the right tool when your needs cross a few lines. Watch
for these:

- **Scale.** You're approaching the record cap, or the base is sluggish under
  daily use. Millions of rows is a database job, not an Airtable job.
- **High-volume writes.** Thousands of records changing per minute - a busy
  web app's backend, live event data - is past what Airtable is built for.
- **Powering a public product.** If real customers hit it constantly through
  an app or website, you want a proper database (Postgres, MySQL) behind a
  real backend. Airtable's API has rate limits that a public product will
  trip.
- **Strict integrity and complex rules.** When you need guarantees a typical
  spreadsheet-style tool doesn't enforce - transactions, intricate
  validation, audited access - that's database-and-engineer territory.

Here's the clear-eyed framing. Airtable is excellent at being the **operational
hub for a team**: pipelines, content calendars, inventory, project tracking,
applicant lists, anything where a handful to a few hundred people manage
thousands to tens of thousands of records together. It is not the engine for a
consumer product or a data warehouse, and trying to force it into that role is
how you end up fighting the tool.

The graceful path is to let Airtable be the prototype. Build your idea in it
fast, learn what the data and the workflow really need, and run on it as long
as it's comfortable. When you hit the walls above - and you'll feel them
coming - that's your signal to move the heavy part to a real database, often
keeping Airtable around as the friendly internal admin view on top. Knowing
where that line is, before you slam into it, is the difference between a tool
that served you well and a migration you did at 2am.