You went to add a record and Airtable stopped you. The base is full. The thing you were trying to add is real, a new client, a new order, a new applicant, and right now it lives nowhere except your head.
Then you look at the ways out and each one has a price. Upgrade, and you start paying per person for everyone who touches the base. Delete records, and you lose history you might want in January. Split the base in two, and you break the links between tables, which were the reason you stopped using a spreadsheet in the first place.
There is a fourth option. It works for most bases that hit the cap, and only because of an unremarkable fact about what is in them: most of it is finished.
The short answer
Airtable's Free plan allows 1,000 records per base. Once a base is over that line you can still open it, read it, edit what is there, filter it, and report on it. What you cannot do is create anything new. Airtable's own documentation is blunt about it: bases that exceed the Free plan's record limit "can't create new records, including records added through forms or the Airtable API."
Two things get you back under: remove records, or upgrade. There is no third mechanism, and anyone selling you one is selling you something else.
The useful move is to notice that "remove records" does not have to mean "lose records." Push the finished ones into a Google Sheet where they stay searchable and permanent, then delete them from the base. The base holds live work only, and the history sits somewhere safer than a base you were about to prune anyway.
Syncing to Google Sheets does not raise the cap
Say this first, because the rest of the article depends on you believing it.
No sync tool, ours included, changes Airtable's record limit. The cap is enforced inside Airtable, on the base. A copy of your data sitting in a spreadsheet has no effect on it. Sync 1,000 records to a Sheet and change nothing in Airtable, and you are still at 1,000 records with Airtable still refusing the next one.
What the sync is good for is making the delete survivable. Deleting is the only free way back under the cap, and the reason people will not do it is that the records still mean something. A sync gives them a permanent home outside Airtable first, so the delete becomes a move rather than a loss. That is the whole contribution, and it is a smaller claim than this category usually makes.
What the cap actually blocks
The limit is per base, not per workspace and not per table. Every record across every table in one base counts toward the same 1,000, and Airtable's plans page notes that a single table reaching 1,000 hits the base limit on its own. Other bases in the same workspace get their own 1,000 each.
Once you are over, here is the split.
Still works: viewing every record, editing existing records, filters, sorts, groups, views, formulas, charts, sharing a view, exporting to CSV, and syncing out to a spreadsheet.
Blocked: creating a record by hand, a form submission creating a record, an automation creating a record, and anything an outside tool creates through Airtable's API. Airtable's documentation on changing plans puts it plainly: "you can't add new records or attachments until you're back under the limit."
That last one is worse than it sounds. A public intake form stops accepting submissions and nobody watching it will know. If a form points at a base near the cap, treat this as urgent rather than annoying.
Record limits by plan
| Plan |
Records per base |
Attachment space per base |
Revision history |
Price |
| Free |
1,000 |
1 GB |
2 weeks |
$0 |
| Team |
50,000 |
20 GB |
1 year |
$20 per user per month, paid annually |
| Business |
125,000 |
100 GB |
1 year |
$45 per user per month, paid annually |
| Enterprise Scale |
Not published |
Not published |
Not published |
Sales-priced, contact Airtable |
Checked against Airtable's plans documentation and pricing page on 22 July 2026. These figures move, so verify before you budget around them. Airtable does not publish Enterprise Scale limits on its plans page and third-party numbers for that tier are not worth repeating.
The jump matters more than the numbers. Free to Team is 1,000 records to 50,000, and the price is per person, not per base. Five collaborators on Team is $100 a month. That is the real decision in front of you.
Two workarounds that cost more than they save
Both come up in every forum thread on this. Both work in the narrow sense and damage something you will miss.
Splitting one base into several
The cap is per base, so two bases give you 2,000 records. Free. Done.
Except linked records do not cross bases. A link field can only point at a table inside the same base. Split Projects away from Clients and every link between them breaks, along with every rollup and lookup reading through those links. Your total invoiced per client stops calculating. Your project view that showed the account manager goes blank.
Those relationships are why you chose a database over a spreadsheet. Splitting the base to stay free trades away the one thing you were getting for nothing and could not get anywhere else, and leaves you with two disconnected spreadsheets that happen to run inside Airtable. Airtable's own base-to-base sync would reconnect them, but sync is not available on Free plan workspaces, so as a free workaround it does not close the loop.
Deleting records until you fit
This works, and it is the right instinct pointed at the wrong target. The problem is doing it without a copy.
Free-plan revision history is 2 weeks. Delete a record, change your mind five weeks later, and there is no version of the base to go back to. The dates, the notes, the amounts are gone. People find this out at year end, when someone asks what the average project value was and the answer is that half the year was deleted in March to make room.
Deleting is fine. Deleting without a copy is the mistake.
The pattern that works: archive, then sync
Look at what is actually in a base at the cap. It is almost never a thousand live things. It is a small number of live things and a large pile of finished ones: shipped projects, paid invoices, closed tickets, rejected applicants, last season's inventory.
That reframes the whole problem. You did not outgrow Airtable. You outgrew keeping finished work inside it. The finished records do not need links, views, statuses, or automations any more. They need to be findable and countable, which is a spreadsheet's entire job.
So: push the finished ones into a Google Sheet, confirm they landed, delete them from the base. The base drops back under the cap and gets faster to work in, which an upgrade would not have fixed. The history sits in a spreadsheet with no record limit, that anyone can open without an Airtable seat, and that you can pivot, QUERY and chart against. If reporting on the archive is the point, building the report on a synced tab is a separate skill worth learning once.
How to archive without losing records
Order of operations is the whole thing here. Get it wrong and you delete data you have not copied yet.
1. Build the view in Airtable first. A new grid view filtered to the records you are willing to let go. Status is Done, or Closed date is before 1 January. Do not select rows by eye. The view is what you copy and also what you delete, so the two are guaranteed to match.
2. Sync that view into its own spreadsheet. Not a tab in your live report. A separate file called something like "2025 archive." Any of the methods in the sync guide moves a view across, including a plain CSV export for a one-off.
3. Check what landed, in the spreadsheet, with your eyes. Row count matches the view's record count. The columns you might be asked about are present and readable. Dates look like dates. Two minutes, and it is the step everybody skips.
4. Only now delete in Airtable. Open the same view, select all, delete. You are under the cap and can add records again.
Never reverse steps 3 and 4. There is no undo worth relying on with two weeks of revision history.
The append-versus-replace trap
A sync that mirrors an Airtable view rewrites its tab on every run. That is correct behaviour for a live view and wrong for an archive, because the moment you delete the records in Airtable the view is empty, and the next sync writes an empty tab over your only copy.
So the archive must live on a tab no sync ever writes to. After step 3, copy the synced tab into a plain sheet, or duplicate it and rename it. Then delete in Airtable. If you are running a scheduled sync, turn it off for that spreadsheet once the archive is made. An archive that a scheduled job can overwrite is not an archive.
What happens to attachments
Attachments do not survive the trip and you should plan around that.
Airtable hands over a web link for each attached file, and it only guarantees that link stays alive for at least 2 hours. Your archive keeps the filename and a link that will stop working, not the file. If the contracts and photos attached to those records matter, download them into a Drive folder before you delete anything. The full explanation of attachment behaviour covers why this happens on every export and sync method, not just one.
One free-plan limit that catches sync tools
Before you set anything up on a timer: the Free plan also allows 1,000 API calls per workspace per month. Every sync tool spends those, ours included. Airtable gives a one-time 30-day grace period, after which calls over the limit are blocked until the month resets.
The arithmetic is friendly for an archive and unfriendly for a schedule. Airtable hands back records 100 at a time, so copying a 1,000-record view costs roughly ten calls plus a little overhead. Do that a few dozen times a month and you are fine. A sync running every three hours is about 240 runs a month, and it will run you out well before month end.
So on a Free plan, run the archive when you need it rather than on a schedule. Keeping a spreadsheet current on its own is a scheduling question, and it assumes a plan with room for the calls.
When to stop archiving and just pay
Archiving is the right tool for one shape of problem: a base where most records are finished. If that is not your base, it is the wrong tool and stretching it will hurt.
Pay for Team if:
- The thousand records are all live. A thousand active SKUs is a thousand things you need to link, filter and edit. There is nothing to archive.
- You need more than five people with edit access. Free tops out at 5 collaborators with Editor or Creator permissions regardless of records, so seats will cap you before records do.
- You need forms accepting submissions with no supervision. A form pointed at a base that drifts back over the cap fails quietly.
- You need more than two weeks of revision history, or more than 1 GB of attachments per base.
At $20 per user per month paid annually, two people on Team is $480 a year for fifty times the records. If the base really is full of live work, that is a fair price and the archiving dance is unpaid labour.
Archive when a paid plan would only buy you room to keep hoarding records you were never going to open again.
Common questions
Does exporting or syncing to Google Sheets raise my Airtable record limit?
No. The limit is enforced inside Airtable on the base itself. A copy in a spreadsheet has no effect on it. The only things that get you back under are deleting records or upgrading the plan. Syncing makes deleting safe, which is a different and smaller claim.
Is the 1,000-record limit per base or per table?
Per base. Every record in every table of that base counts toward the same 1,000. Airtable's plans documentation notes that one table reaching 1,000 records hits the base limit on its own. Other bases in the same workspace get their own 1,000 each.
Can I still edit and view records once I hit the cap?
Yes. Reading, editing, filtering, grouping, formulas, charts, view sharing and exporting all keep working. What stops is creation: manual records, form submissions, records created by automations, and records created through Airtable's API.
What happens if I downgrade a paid base that already holds more than 1,000 records?
Your records stay. Airtable's documentation on changing plans states that if a base is over the Free plan's limits you cannot add new records or attachments until you are back under. Nothing is deleted for you, and nothing is hidden. The base is simply frozen for additions.
How many API calls does an archive sync use on the Free plan?
Airtable returns records 100 at a time, so a 1,000-record view costs roughly ten calls plus a small amount of overhead, against a Free-plan allowance of 1,000 calls per workspace per month. Occasional archiving fits comfortably. A sync running every three hours does not.
Should I split my base into several bases to stay free?
Only if no table in it is linked to another. Link fields work inside a base and not across bases, so splitting breaks every link, rollup and lookup that crossed the line you drew. Base-to-base sync exists to reconnect them, and it needs a paid plan, which defeats the purpose.
What to do next
If your base is mostly finished work, build the view of finished records today, copy it into a spreadsheet, check the rows landed, and then delete. You will be under the cap in twenty minutes and you will have a permanent archive you can actually report on, which the base was never giving you anyway.
If your base is mostly live work, upgrade and stop spending evenings on this.
For the archive itself, the four ways to move Airtable data into Google Sheets covers which method suits a one-off archive and which suits a spreadsheet you want kept current. Airtable to Sheets is one of them, and its pricing is flat per account with no per-user charge, which is on the pricing page.
