Loading tutorials…
Loading tutorials…
Airtable feels fast until your base hits a wall — usually around 10K records on Team or 50K on Business. The wall is rarely the record count itself; it is what you built on top of it. This walks the diagnostic sequence specialists run.
Who this is forAnyone running an Airtable base that has become sluggish, is approaching plan record limits, or has automations that fail silently. If saves take 5+ seconds, the Grid feels laggy, or you keep hitting 'upgrade your plan' modals, this tutorial is for you.
What you'll need
Step 1
Free: 1,000 records per base, 100 automation runs/mo. Team ($20/user/mo): 50K records, 50K runs. Business ($45): 125K records, 100K runs. Enterprise: 500K, 500K.
Open Airtable → Avatar (top-right) → "Workspace settings" → "Billing." Confirm your current tier and seats.
For each base, click the base name → "Base settings" → check current record count (top of the panel).
Settings → "Automations" → see monthly run count vs limit. Free is 100/mo, Team 50K, Business 100K, Enterprise 500K+.
Settings → "Attachment usage" → check storage. Free: 1GB total. Team: 20GB per base. Business: 100GB per base. Attachments often blow before record limits.
Confirm field count: Free supports basic fields; some advanced fields (formulas, rollups, lookups) are Team+.
Step 2
Slowness has 4 main causes: hitting record count, complex formula chains, runaway automations, attachment-heavy records. Diagnose before fixing.
Record count near limit: open Base settings → check record counts per table. Sum them. If you are at 85%+ of your tier limit, that is the issue.
Slow saves on edit: usually formula recalculation. Open each table → look for tables with 10+ Formula, Rollup, or Lookup fields. These are slow on every save.
Automation timeouts or failures: Automations panel → Run history → look for "Failed" runs. Common causes: rate-limited external calls, scripts that timeout, automations triggered too frequently.
Attachment bloat: tables with Attachment fields holding large images/videos slow down view loads and exports. 50MB+ per record means trouble at any scale.
Slow Grid scrolling: too many records visible at once. Default view should be filtered to <2,000 visible records.
Step 3
Most bases have 30-60% of records that are historical and no longer edited. Move them to an "Archive" view or a separate base.
Identify archive candidates: records with Status = "Archived" / "Closed" / "Lost" / "Published > 6 months ago."
Option A — Archive view: filter them out of active views. Records stay in the base but do not appear in daily-driver views. Easy, but record count stays high.
Option B — Separate Archive base: on Team+ tier, use Sync to push old records to a separate "Archive" base, then delete from the main base. Best for bases approaching record limits.
Option C — CSV export + delete: export the records to CSV (stored externally), then delete from the base. Simplest, but the data is no longer queryable in Airtable.
Before deleting: verify no automations, views, or interfaces depend on the records being present.
Step 4
Formula fields that depend on rollups that depend on lookups create slow recalculation trees. Flatten where possible.
Audit every Formula field for complexity. Anything more than 5 lines of formula or 3 levels of IF nesting is a candidate.
Audit every Rollup that depends on a Linked record field with 1,000+ linked records. Each linked record recalculates on every save — slow.
Audit every Lookup that depends on a Formula in the linked table. Formula-on-Lookup chains are slow.
Refactor: cache derived values in regular fields, updated via a daily scheduled automation. The Number field is fast; the Formula field is slow at scale.
For dashboards on large datasets, consider building summary tables: a daily automation aggregates raw rows into a "Daily Summary" table with pre-computed metrics. Dashboards point at the summary table, not the raw table.
Step 5
A single misconfigured automation can fire 10K times in a day. Audit run counts per automation.
Automations panel → for each automation → click → "Run history" → see how many times it fired this month.
Identify automations firing more than 1,000x/month. For each, check the trigger: is it too broad?
Common runaway pattern: "When record updated" trigger without a Single select equality condition → fires on every field edit, including formatting and rapid bulk edits.
Fix by adding conditions: Status = "Specific value" so the automation only fires on real transitions, not every edit.
Audit run counts monthly. Compare against your tier limit. If you hit 80% in week 3, you have a leak.
Step 6
Attachments dominate Airtable storage. 1MB images compound fast at 10K records. Move heavy assets to S3, Google Drive, or Cloudinary.
Identify attachment-heavy tables: anywhere with an Attachment field holding images, videos, or PDFs.
For each Attachment field, ask: do I need the file inside Airtable, or just a link to it?
For most marketing use cases, a URL field linking to Google Drive, Dropbox, S3, or Cloudinary works as well — and does not count toward Airtable storage.
Pattern: keep one canonical-version attachment inside Airtable (the published version). All drafts, source files, and historical versions live on external storage.
For large bases, this typically reclaims 50-80% of attachment usage.
Step 7
After diagnosis, the right answer is one of: upgrade tier (simplest, costs $), refactor (saves $, takes time), or move workload (different tool for different job).
Upgrade tier if: you are at 80%+ on record count AND the data is genuinely all needed AND the team is happy with current performance. Team → Business is ~2x cost but ~2.5x record limit + better attachment storage.
Refactor if: bottleneck is formula chains, attachments, or automations — not record count. Refactoring is cheaper but takes 1-2 weeks of focused work.
Move workload if: a specific use case is the bottleneck and another tool is genuinely better. Examples: move file storage to S3/Cloudinary, move email sequencing to a dedicated tool, move customer data to a real CRM, move large transactional data to a Postgres database with sync.
Common decision: Airtable for ops + content + lightweight CRM. Postgres or BigQuery for transactional data. S3 for files. Dedicated CRM (HubSpot) when sales scale.
Common mistakes
Treating Airtable as infinite storage
What goes wrong: Stuffing 100K records, 30 attachment fields, and 200 automations into one base. Saves take 8 seconds. Views take 12 seconds to load. Team productivity drops 30%. At a 10-person team, that is ~$15-30K/quarter of lost time.
How to avoid: Airtable is a relational ops layer, not a data warehouse. Move historical/transactional data to a real database with Sync into Airtable for active operations.
Storing originals of all images and videos inside Airtable
What goes wrong: Marketing base hits the 20GB attachment limit on Team tier in month 9. Cannot upload new assets. Team scrambles to find what to delete. ~$500/mo upgrade to Business tier just for attachment space, when S3 at $5/mo would have worked.
How to avoid: Use Airtable Attachment fields for one canonical/published version. Link to external storage (S3, Cloudinary, Google Drive) for source files and drafts. URL field is free; attachment fields are billable.
Broad "When record updated" automation triggers
What goes wrong: A 'notify on any change' automation fires 18,000 times in a month from a 600-row table with daily edits. Team hits the 50K automation run cap by day 22. Notifications stop firing for the last week of the month. ~$200-500 in upgraded tier costs to fix what conditions would have solved.
How to avoid: Add Single select equality conditions to every "When record updated" trigger. Audit run counts monthly.
Formula chains that recompute on every edit
What goes wrong: Formula depends on Rollup depends on Lookup depends on Formula. Editing any one field triggers a 4-level recalculation. Saves take 6-12 seconds on busy tables. Team avoids using the base ('it is too slow'). ~$1-3K/mo of lost productivity until refactored.
How to avoid: Cache intermediate values in regular fields via daily automations. Dashboards point at the cached fields, not the live formula chains.
No archive strategy
What goes wrong: Records from 3 years ago still live in the active base. Views are slow. Searches scan 50K rows. Approaching record limit forces tier upgrade. ~$1-3K/yr of plan overage that archive would have prevented.
How to avoid: Quarterly archive routine: records with Status = Closed/Archived/Done from >12 months ago move to an Archive base (via Sync or CSV export). Active base stays lean.
Treating tier upgrade as the only solution
What goes wrong: Hit Team limits → upgrade to Business → hit Business limits → upgrade to Enterprise. Cost goes from $20/user/mo to $54/user/mo to $250+/user/mo without addressing the root cause. For a 10-person team, this is the difference between $2,400/yr and $30,000/yr.
How to avoid: Diagnose first. Most slow bases are structural, not record-count problems. Refactor the structure before upgrading the tier.
Recap
Done — what's next
How to use Airtable formulas, rollups, and lookups without making your base unreadable
Read the next tutorial
Hand it off
Airtable performance problems compound. Every week of slow saves is a week of degraded team productivity worth $1-3K. A specialist will diagnose the bottleneck, refactor the structural issues, and document the new pattern in 4-6 hours — typically $300-500 one-shot, vs the $5-15K/yr cost of unnecessary tier upgrades.
See specialist rates
You can no longer create new records in that base until you (a) delete records, (b) archive records to a separate base, or (c) upgrade tier. Existing records remain editable. Imports fail silently — you may not realize you stopped capturing data until much later. Always set up an alert (a webhook automation that pings #ops-alerts at 90% capacity).
Yes. Synced records count against the destination base's record limit, even though the source-of-truth lives elsewhere. Plan accordingly when syncing large datasets — sometimes a filtered sync (only active records) is the right pattern.
Three signals: (1) Saves on edit take 3+ seconds (normal is sub-second). (2) Views with formula fields take 5+ seconds to load. (3) Bulk edits or imports hang or fail. Diagnose by temporarily disabling complex formula fields and observing the change in save time — if it speeds up, you found the bottleneck.
Sometimes. Sync (Business+) is good for: read-only mirrors of source-of-truth data, archive bases, departmental views of a master base. Sync is poor for: bidirectional editing (it is one-way), real-time operations (lag is 1-3 minutes), high-frequency updates (rate-limited). For most performance problems, refactoring inside one base beats splitting.
When: (a) record count is in the hundreds of thousands and growing, (b) you need true OLTP performance, (c) you have transactional volume (orders, events, logs) that does not need ops collaboration, (d) compliance requires more control than Airtable offers. Typical pattern: Postgres or BigQuery as the system of record, Airtable as the operational UI for the subset of data the team actively works on.
Airtable
Most Airtable bases use 10% of the formula engine. The other 90% is what separates a 'fancy spreadsheet' from a real ops system. This walks the patterns that matter — and the formulas that should never have been written.
Airtable
Airtable automations are powerful, native, and brittle if you wire them wrong. Most bases past 20 automations have 5-8 that silently fail every week. This walks the patterns that hold up.
Airtable
Airtable becomes 10x more valuable when it talks to the tools the team already uses — Slack, Gmail, Google Calendar, Mailchimp, HubSpot, your CMS. This walks the integration patterns that hold up past the first sync.
Airtable
DIY Airtable is a great idea — until it isn't. This is the honest framework: when the cost of self-managing a base exceeds the cost of hiring help, and how to tell which side you're on.