BaseBrainers | Airtable Performance Tuning: Why Big Bases Get Slow and How to Fix Them

There is a moment in the life of most successful Airtable bases where it stops feeling instant. Grid views take a beat to paint. An interface page spins for four seconds. Someone edits a status field and the tab freezes while a hundred formulas recalculate. Nobody changed anything — the base just grew.

This tutorial is a diagnostic routine for exactly that situation. It assumes you already have a working base with real data in it and you want it fast again, without a rebuild.

First, measure the right thing

"Airtable is slow" is four different problems wearing one coat. Before touching anything, work out which one you have:

Loading is slow, using it is fine. The base takes ten seconds to open, then behaves. That is a volume and view problem — too many records and fields being fetched up front.
Editing one cell is slow. You type, and there is a visible lag before the value settles. That is a dependency problem — formulas, rollups, and lookups recalculating downstream.
Interfaces are slow, grids are fine. That is usually an element problem — too many list/chart elements on one page, each running its own query.
Automations are slow or queued. That is a throughput problem — run volume, per-run duration, or plan limits.

Time it with a stopwatch on a specific action and write the number down. You need a baseline, otherwise every fix will feel like it helped.

A quick isolation trick: duplicate the base without records. If the empty copy is instantly fast, your problem is data volume. If it is still sluggish, your problem is structure — fields, formulas, and views — and no amount of archiving will save you.

Culprit 1: rollup and lookup chains

The single most common cause of edit lag. A rollup on Clients sums a rollup on Invoices which sums a formula on Line Items. Change one line item and Airtable recalculates the whole chain, plus every formula that references any link in it.

What to do:

Map the chain. For each expensive-looking field, note what it depends on. Three layers is normal. Five or more is where things get sticky.
Collapse the middle. If a mid-chain rollup exists only to feed the next one, see whether the top-level rollup can read the source directly with a condition.
Freeze the slow-moving values. Lifetime totals, prior-year revenue, and closed-project summaries do not need to be live. Have a scheduled automation write a plain number field once a night. A static number costs nothing to display and nothing to recalculate.
Watch ARRAYJOIN on big link fields. A lookup across a linked field holding 2,000 records is expensive every single time it renders.

Culprit 2: link fields with enormous cardinality

A Company record linked to 40,000 Events records is technically legal and practically painful. Every view that shows that link field has to render 40,000 chips' worth of references, and every rollup over it aggregates 40,000 values.

Fixes, in order of preference:

Insert a junction or period table. Link Company → Monthly Activity (12 records a year) → Events. Rollups run over twelve records instead of forty thousand.
Do not display the giant link field in any default view. Keep it, hide it.
Move genuinely historical rows out of the linked table entirely (see archiving below).

Culprit 3: unfiltered, unsorted, over-wide views

A grid view with no filter, sorted by a formula field, showing 60 columns, is the worst-case fetch. Airtable has to evaluate the sort across every record before it can show you the first one.

Give every working view a filter that keeps it to what someone actually works on: Status is not Done, Modified in the last 30 days, Owner is current collaborator.
Sort on plain fields (date, autonumber, single select) rather than formulas where you can.
Hide fields you do not use in that view. Hidden fields are not rendered.
Delete abandoned personal views. They are cheap individually and they add up in busy bases.
Group sparingly. Grouping by a high-cardinality field creates thousands of collapsible groups the browser has to lay out.

Culprit 4: attachment bloat

Attachments do not slow down record queries much, but they consume your workspace's storage allowance fast and they make grid views feel heavy when thumbnails render. If a base holds every signed PDF since 2019:

Keep files in Drive, SharePoint, or S3 and store the URL in Airtable, with the attachment field reserved for things people genuinely open inside the base.
Hide attachment fields from default grid views so thumbnails are not fetched on load.
Audit with a rollup: a formula field measuring attachment count per record, summed per table, tells you where the weight sits.

Culprit 5: automations doing too much, too often

Symptoms: runs stuck in a queue, automations firing hundreds of times an hour, or a "when record updated" trigger that watches all fields.

Always scope the trigger. "When record updated" with no field list fires on every keystroke committed anywhere in the row, including on fields written by other automations — which is also how loops start.
Prefer "when record enters view" with a tightly filtered view over "when record matches conditions" on a hot table.
Batch. One scheduled run at 6am that processes 500 records is cheaper and calmer than 500 individual triggered runs.
Watch run duration in the automation run history. Scripts that page through an entire table on every run are prime candidates for a filtered view instead.
Check your plan's monthly automation run allowance before you scale a per-record pattern. Costs land quietly.

Culprit 6: interfaces that query everything

An interface page with eight elements runs eight queries. A record-list element pointed at an unfiltered source with a formula sort is as expensive here as it is in a grid.

Point each element at a purpose-built view, filtered and sorted, rather than at the whole table.
Split a heavy dashboard into two pages. People rarely need all of it at once.
Use filters that resolve to few records: current user, current month, open only.
Charts over large tables are better fed by a small pre-aggregated summary table that an automation refreshes nightly.

Culprit 7: sync overhead

Synced tables re-pull on a schedule. Several multi-source syncs, each pulling wide tables, produce a steady background load and a lot of change events — which then trigger automations, which then update formulas. If your base gets slow on a rhythm, check your sync intervals.

Sync only the fields the destination needs, sync from a filtered view at the source, and lengthen the interval for anything that is not genuinely time-critical.

Culprit 8: you are simply near the ceiling

Every Airtable plan has a per-base record cap, plus limits on attachment storage, automation runs, and revision history. Performance degrades before you hit a hard limit, not at it. Check your current record counts against your plan's stated limits in workspace settings, and if a single table is carrying six figures of rows, plan a structural change rather than another round of micro-optimisation.

The archiving pattern

Most bases are slow because they are storing history in the working table. Split the two:

Create an Archive table (or a separate archive base) with the same schema, minus the formula fields you only need while work is live.
Add a view on the working table: Status is Done AND Completed before 12 months ago.
Build a scheduled automation: find records in that view, create matching records in the archive, then delete the originals. Run it monthly.
Test on ten records first. Log the archived record IDs somewhere before deleting anything, and take a snapshot of the base before the first real run.

Reporting that needs the whole history reads the archive, which nobody has open all day. The working base stays small and fast.

When Airtable is no longer the right store

Be honest about the ceiling. Move the high-volume data out when you see:

A single table growing by six figures of rows per year — event logs, telemetry, transaction lines, IoT readings.
Reporting that needs joins across millions of rows.
Real-time write throughput from an application, rather than human editing.

The usual pattern is a hybrid: Postgres, BigQuery, or Snowflake holds the raw volume; Airtable holds the operational layer — the records people touch, decide on, and route — with aggregates pushed in on a schedule via the API. You keep the interface and automation experience your team likes without pretending Airtable is a warehouse.

A one-hour tune-up checklist

Baseline three timings: base load, cell edit, slowest interface page.
List every view; filter or delete the unfiltered ones.
Hide unused fields in the default views of your two biggest tables.
Find your deepest rollup chain and freeze the top layer to a nightly number.
Scope every "record updated" trigger to specific fields.
Check automation run history for anything over 30 seconds.
Compare record counts and attachment storage with your plan limits.
Re-time the same three actions and record the improvement.

Most bases we audit get 50–80% of their responsiveness back from the view and trigger fixes alone, before any archiving.

If your schema is the real problem, the fix starts one level up — see our guide to linked records and junction tables. And if a base has grown past what a tune-up can fix, BaseBrainers does structural rework as part of enterprise-level Airtable solutions and database design. Tell us what's slow and we'll take a look.