What you can export from Airtable today
If a renewal, a price change or a residency requirement is pushing you out of Airtable, start by inventorying what you can take out. Airtable does not export a full base as a single file. Each table is downloaded as its own CSV from a view, so a base with twelve tables means twelve separate exports. Check the view you pick for each table, because the file reflects that view's contents. Ask your Airtable administrator which tables, views and attachment fields your team depends on, and record that list before you count the export as complete. The Airtable views guide explains how views are set up.
The CSV covers record values but not everything around them. Attachment links expire after a few hours, so a file URL saved from last week's export will likely fail when you try to download it. Pull attachments in the same session as the table export, or fetch them through the API. Comments and field descriptions are not included in the export either, so the context your team wrote into fields and discussions has to be copied by hand or kept in a separate document. Test one table end to end, including its attachments, before you commit the whole migration plan to CSV downloads.
For a complete extract, the Web API is the route, and it carries its own limits. Airtable's plans overview caps API calls per workspace per month at 1,000 on Free and 100,000 on Team, so confirm your plan's quota before you script a full pull. Requests against a single base are also rate limited, which means a large extract should run as a long job that pauses and resumes after throttling. Confirm with Airtable where your workspace's data is held, because data residency in Europe or Australia is available only on Enterprise Scale and base metadata stays in US data centers.
Which data types leave Airtable, by export method
This table compares each kind of Airtable data with the export route that carries it, the format it arrives in, and the limits that apply. Read it before planning a download, because the CSV route works table by table and the API route is throttled. The main takeaway is that a complete extract usually combines CSV for records, separate attachment downloads and API calls for anything the CSV omits.
| Data type | Export method | Format and limits | What to check |
|---|---|---|---|
| Records and fields | CSV download from a view | One CSV per table or view, with no whole-base file. Records per base are capped at 1,000 on Free, 50,000 on Team and 125,000 on self-serve Business. | Confirm the view shows every record and field before downloading. |
| Attachments | Attachment links in CSV cells | Links expire after a few hours, so files must be fetched promptly. | Download files in one pass and match them to records by name or ID. |
| Field types and computed fields | Values in CSV or API responses | Formula, lookup and rollup results arrive as values, and some field types may flatten. | Compare each field type in the file against the Airtable field settings. |
| Comments, descriptions and history | Not included in CSV | Field descriptions and comments do not appear in the export. | Record them separately, for example from screenshots or a manual log. |
| Full programmatic extract | Airtable Web API | A per-base rate limit applies. API calls are capped per workspace per month at 1,000 on Free and 100,000 on Team. | Confirm the current rate limit with Airtable and plan pagination and request budgets before a large run. |
What does not export and how to work around each gap
Airtable's export tools move table data and attachments, but several things stay behind: whole-base files, durable attachment links, comments, field descriptions and the logic built around the data. Each gap below needs a planned workaround before cutover, and the cards are ordered from the most structural to the easiest to recreate by hand.
No whole-base single-file export
Airtable does not export a full base as one file. Each table is downloaded as its own CSV from a view, so the extract is only as complete as the views you export. Before you start, list every table and confirm that each has a view with no hidden fields or filters. Then export each table from that view and keep a manifest that records table name, view name, row count and export date. Reconcile row counts against Airtable after each download. Importers such as Baserow's and Grist's can read a base directly, so check whether a direct import is a better path than CSV files.
Attachment links that expire
Attachment URLs in an Airtable CSV are temporary and stop working after a few hours. A CSV holding dead links preserves the filename and the record but not the file itself. Download attachments in the same session as the export, or pull them through the Web API while the links are still valid. Store each file under a stable path that includes the record ID and field name, and record the mapping in your manifest so the files can be re-linked after import. Verify a sample of files by checksum before you decommission the base.
Comments and revision history
Record comments and their authors are not in CSV or API field exports in a form that imports cleanly, and revision history is not carried over either. If comments hold decisions or approvals, you need a written record. Use the Web API or your own review of each record to copy comments into a notes field, a separate table or an exported document, with the author and date. Confirm which comment data your plan and API access expose before you rely on it, since availability can vary by plan.
Field descriptions and field metadata
Field descriptions, which explain what each column means and which values are allowed, are not part of the CSV. Without them, a new schema can lose the business meaning behind names like status codes or cost centers. Copy every field description into a data dictionary before you export, with the field type, options and whether the field is a link or a formula. This dictionary also becomes the checklist you use to rebuild the schema in the target tool and to test that each field type converted correctly.
Interfaces, automations and formulas
A CSV carries values, not logic. Interfaces, automations, and the formula, lookup and rollup definitions that produce those values do not travel in a data export. Baserow's Airtable importer excludes formula, lookup, rollup and collaborator fields, automations, interfaces, comments and revision history. Document each automation trigger and action, each formula expression and each interface page as a specification. Rebuild these in the target platform and run old and new outputs side by side before cutover.
Full extracts through the Web API
For a complete extract, the Web API is the documented path, but it is throttled per base and per workspace. Plan requests against the limits in your plan and confirm the current rate limit in Airtable's API documentation before you schedule a run. Pull records, attachments and metadata in batches, save raw responses, and resume from the last saved page after an interruption. Keep the API key or token out of scripts that others can read, and revoke it once cutover is complete.
Sequence for a complete, verified export
This sequence turns a live Airtable workspace into a set of copies you control, with a written record that each table, row, field and attachment was counted and checked against the source before you rely on the copies or start a migration. Because Airtable has no whole-base export, the work is assembled from per-table CSVs, the Web API and attachment downloads, and each step closes with evidence you can keep.
Inventory tables, views and attachments
Before exporting anything, the base owner lists every base in scope, every table in each base, the views each table uses, and the attachment fields that hold files. Record the base ID, table name, view name, record count shown in the interface, field count and the number of attachments per attachment field. Export this inventory as a dated file and store it with the export. The step is done when every table in scope has a row in the inventory and the counts are noted, so later checks have a baseline to compare against.
Freeze the schema and record changes
Ask base editors to stop changing field names, field types, formulas and table structure for the duration of the export, and note who approved the freeze. Take a screenshot or a field-by-field list of each table's fields, types and any formula text, since Airtable's CSV download carries values but not the field configuration. Record the time the freeze started and ended. The step is done when the schema list is saved alongside the inventory and the freeze owner has confirmed in writing that no structural edits were made.
Export each table as CSV from a complete view
For each table, create or select a view that shows all rows and all fields, with no filters, hidden fields or grouping that would drop data. Download the CSV from that view, since Airtable does not export a full base as one file. Name each file with the base and table, and keep the view name in the inventory. Check that the downloaded file's row count matches the record count in the inventory and that the column headers match the field list. The step is done when every table has a CSV and its row and column counts match the inventory.
Pull records and attachments through the Web API
Use the Airtable Web API with a token that has read access to the base to extract records, including fields that the CSV does not represent cleanly, such as linked record IDs and attachment metadata. Pace the requests within the per-base rate limit, and log every page returned, the HTTP status and any retries. Download each attachment file promptly, because attachment links in Airtable expire after a few hours, and save each file under a stable name tied to its record ID and field. The step is done when the API extract's record count matches the inventory and each attachment has a saved file.
Store the copies under your own control
Move the CSVs, API extracts, attachment files, schema list and inventory into storage that your organization controls, such as an encrypted volume on your own servers or a bucket in your own cloud account. Restrict access to the people who need it, and record where each copy lives and who holds access. Compute a checksum for each file and store the checksum list with the export. The step is done when every artifact is in the controlled location, the checksum list exists, and access has been limited and documented.
Verify row counts and field values
Compare each table's CSV row count and the API record count with the inventory. Then sample records from each table and compare field values with the live base, paying attention to dates, numbers, multi-select fields, linked records and long text, where formatting is most often lost. Note any mismatch, its cause and the fix. The step is done when counts match for every table and the sampled records match, or each difference is explained in the verification log.
Verify attachment file counts and sign off
Count the attachment files saved for each attachment field and compare them with the counts in the inventory and in the API extract. Confirm that each file opens and that its checksum matches the stored list. Record any attachment that failed to download, with its record ID, so it can be retried before links expire. Once the checks pass, the export owner signs a single record that lists the inventory, schema list, verification log and checksum list. The step is done when the attachment counts match, the files open, and the signed record is stored with the export.
How the API route differs from CSV downloads
Use the Web API when you need a complete extract that a CSV download cannot give you. Airtable exports one table at a time from a view, so hidden fields, filtered-out rows and linked records outside that view can be missed. A script that reads each table through the API can capture every record, record identifier and linked-record reference in a structured form. Before you write it, confirm the endpoints and field coverage in Airtable's developer documentation, and check the monthly API call allowance for your plan in the Airtable plans overview. The per-base rate limit is the constraint that shapes the job: plan the run as a queue of tables, pace requests below the limit, back off when the API signals throttling, and log each completed table so a failed run can resume without starting over.
Attachments need their own handling in the API route. The attachment URLs returned with records are temporary, and so are the links in a CSV, so storing only the URL leaves you with broken references later. Download each file in the same run that reads its record, save it under a stable name built from the record ID and field name, and check the stored size against the size Airtable reports. Run a test on a small base first to see how long a link remains valid in your workspace. A common decision point is whether attachments download before or after the metadata is written. Downloading first, with a retry for each file, avoids most losses.
The trade-off comes down to effort against completeness. A CSV download needs no code, suits a small base moved once, and lets a non-engineer check the result by eye, but it leaves gaps and depends on manual steps for every table. A scripted extract is repeatable and complete, and it can be rerun before cutover to catch changes, but someone must own the script, handle pagination and errors, and protect the access token. Whichever route you take, compare record counts per table against Airtable's own counts before you retire the source base. Keep the export logs and checksums with the migration record so the copy can be verified later.
Export paths for small bases and large bases
A small base with a few tables, modest attachment counts and no heavy dependencies can usually be exported with Airtable's own tools. Airtable does not export a full base as a single file, so each table is downloaded as its own CSV from a view. Because a CSV reflects what the view shows, the view must include every field and record you need before you download it.
- One CSV per table: Create or select a view for each table that shows all fields and has no filters, then download it.
- Computed fields: Record which fields are formulas, lookups or rollups in your inventory, because the CSV holds their displayed values and not the logic behind them.
- Linked records: Check how linked records appear in the file, and keep a separate map of relationships if you need to re-link them later.
- Team effort: One administrator with edit access to the base can complete the export in one session, with a second person comparing row counts.
Before you treat the export as complete, confirm that each CSV's row count matches the record count Airtable shows for that view.
A base near the plan caps, or one with many tables and long histories, is better extracted through the Web API than through CSV downloads. The API is subject to a per-base rate limit, so the extract should be paced and run across several scheduled windows instead of one continuous burst. Records and API usage are also capped by plan, so the extract's size and frequency must fit inside those allowances.
- Script the pagination: Write a script that reads each table page by page, saves the raw JSON, and resumes from the last saved position after an error.
- Respect the rate limit: Throttle requests and back off when the API signals that the limit has been reached.
- Budget monthly calls: Count the extract's requests against your workspace's monthly allowance, including any test runs and retries.
- Skills and storage: Assign someone who can write and maintain the script, scope the API token to the base being exported, and provision storage for the JSON output.
Before you start, confirm the current rate limit and the token scopes your plan provides, because both are set by Airtable and can change.
Attachment fields hold files on Airtable's servers, and the download URLs returned for them expire after a few hours. A complete export therefore has to fetch each file during the same run that reads its record, or request a fresh URL immediately before each download. Plan the file volume separately from the table data, since attachments often make up most of the storage an export needs.
- Download during extraction: Fetch each attachment as soon as its record is read so the URL is still valid.
- Stable file names: Store each file under its record ID and attachment ID so it can be matched back to its record after import.
- Verify each file: Compare the stored byte count with the size reported in the attachment metadata, and log any file that fails.
- Destination capacity: Size the storage target for the full attachment volume before the run begins, not after it stalls.
Test the full chain on one base with a small set of attachments before you run the complete extract, and keep the failed-file log with the export records.
Export options and limits depend on your Airtable plan and can change, so the export plan should start with what your plan provides. Airtable's plans overview lists records per base and API calls per workspace per month by plan, and these caps determine whether a CSV download or an API extract is practical. Read the current figures on the plans page at the time you export, and keep a dated copy with the project records.
- Record caps: Confirm the records-per-base limit on your plan against the largest table, including growth expected during the export window.
- API allowance: Confirm the monthly API call allowance for your workspace and whether your plan's API access covers the extract.
- Rate limit and token scopes: Confirm the current per-base rate limit and how personal access tokens are scoped for the base.
- Attachment links and residency: Confirm the expiry behavior of attachment URLs, and note that base metadata and user data stay in US data centers regardless of region.
Request written answers from Airtable for any limit your migration depends on, and keep those answers with the export plan.
What to plan before the Airtable contract ends
An Airtable export is only as complete as the views and tokens you prepare for it, and it is easier to test well before a renewal date. The cards below cover the decisions and checks that connect a trial extract, your plan limits, the target platform, audit needs and where the archive lives.
Run a full test extract early
Airtable has no whole-base export, so each table must be downloaded as its own CSV from a view, and attachment links expire after a few hours. Run a complete extract well before the renewal date, not on the last day. Count records and attachments per table, compare them with the source, and note which tables needed manual steps. Any gaps found in a trial still leave time to fix the process. Confirm with Airtable, in writing, what your current contract allows regarding access and data return before you rely on any timing.
Record your plan and seat counts
Write down your current plan, the number of paid seats, and how many records and API calls each base and workspace uses against the plan caps. Pricing and caps change, so take the figures from your own invoice and the current plans page rather than from memory. Seat counts also tell you which target licenses you need, since a self-hosted platform may charge by seat, by instance or not at all. Ask your account team which renewal, notice and data retention terms apply to your agreement.
Decide the target platform
Choose the target before the export, because the platform decides which data survives the move. Baserow's importer copies tables, records, attachments, field types, relationships and grid views from a public share link, but not formula, lookup, rollup or collaborator fields, automations, interfaces or comments. Grist's Airtable import works with personal access tokens. Map every formula, automation and interface you depend on against the target so the gaps are known before cutover.
Confirm regulatory and audit data needs
Before deleting anything in Airtable, decide what records, change history and access evidence your regulators, auditors or internal policies require you to keep. Airtable's exports do not include comments or revision history, so those need a separate retention decision. Ask your compliance lead and external auditor which data sets must be preserved, in what format and for how long. DeployOpen can help prepare the evidence, but auditors and certification bodies decide what is sufficient.
Keep the archive under your control
Store the final export on storage you own, with checksums, a documented file inventory and restricted access. Attachments need their own copy because their links expire. Include the base structure, view definitions and field descriptions you captured by hand, since CSV files do not carry them. Test that the archive can be opened and read by someone who is not the original author, and record who holds the encryption keys and where backups are kept.
Questions buyers ask before exporting Airtable data
How long does a complete Airtable export take?
The duration depends mainly on how many tables the base holds, how many records and attachments each table contains, and whether you script the extract through the Web API. Airtable has no whole-base export, so each table is downloaded as its own CSV from a view, and attachment links expire after a few hours, which means large attachment sets have to be fetched in a single pass. No fixed duration applies to every base, so ask DeployOpen for a written estimate based on an inventory of your tables, views and attachment volume. Use the Airtable views guide to confirm how each table's export works in your plan.
Can our team export the data without outside help?
Yes, for a small base with a handful of tables and few attachments, an administrator can download the CSVs from each view and save the attachments by hand. The effort grows quickly beyond that: each view must be checked for filters that hide rows, linked records lose their meaning in flat files, and attachments must be downloaded before their links expire. Teams with many tables or a Web API extract usually find the verification work is the larger share. Assess your base against those factors before deciding.
What does the export need from admins and developers?
Admins need edit or owner access to every base in scope, plus the ability to create personal access tokens if the extract uses the Web API. Developers need to write a script that respects Airtable's per-base rate limit, pages through records, retries failed attachment downloads and stores the files with stable names. Document the field types and link fields as well, because CSV output does not preserve relationships, comments or field descriptions, so those need a separate record. Confirm current token scopes and limits in your own Airtable plan.
What does a DeployOpen export engagement cover?
DeployOpen works under a written, fixed scope that names the bases, tables, attachments and target platform, and the deliverables and timeline are agreed before work starts. In general terms, the work can include an inventory of bases and fields, scripted extraction, attachment capture, mapping of linked records and a verification report comparing the copy with the source. Ask for the exact list of deliverables in the written scope. DeployOpen does not issue audit reports or certifications for the export.
How do we verify that an Airtable copy is complete?
Compare record counts per table with the counts shown in Airtable, check that every attachment file exists and matches its expected size, and sample records across each table to confirm values, dates and select options survived. Check linked-record relationships by counting references on both sides. Keep a checksum list for attachments and retain the export log so an independent reviewer can repeat the comparison. Agree on the acceptance checks with your data owners before the extract starts.
What drives the cost of an export, and what should we ask for in a quote?
Cost is driven by the number of tables and bases, attachment volume, how many relationships and formula fields must be documented, the amount of scripting, and the verification effort. One-time work covers inventory, extraction and verification. Recurring costs appear only if you need repeated syncs or ongoing support, which are offered as separate retainers. Request a written quote that itemizes each base, the extraction method, attachment handling, verification steps and any retained support. No price is published here.
Does an export preserve comments, automations and interfaces?
No. Airtable's CSV downloads carry field values only, so comments, field descriptions, automations, interfaces and revision history need to be recorded separately from the Web API or by manual documentation. Plan to keep a written inventory of these items so they can be rebuilt on the target platform. Confirm with Airtable which metadata your plan exposes through its API before you assume any of it can be extracted.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Airtable exit, we scope the export path for each base, build the extract and import pipeline on infrastructure you control, and document the result so your team can run it after handover.
How we scope
- Inventory every base, table, view, attachment field and linked record that must leave Airtable
- Record which Airtable features, such as formulas, automations, interfaces and comments, need rebuilding rather than copying
- Agree the target platform, hosting location and access model in a written, fixed-scope document before work starts
How we build
- Run the Airtable extract through the Web API or per-view CSV downloads, sized against the per-base rate limit
- Stand up Baserow or Grist in your environment, with external PostgreSQL where the chosen platform recommends it
- Import tables, attachments and relationships, then check row counts, field types and attachment integrity against the source
How we hand over
- Deliver a runbook covering the export scripts, import steps, configuration files and rollback procedure
- Document the field mapping and every rebuilt formula, view or automation so reviewers can trace each one
- Walk your administrators through the running instance and record the acceptance tests that were passed
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the exit is complete
- Plan platform version upgrades and backups for the self-hosted instance under the agreed scope
- Ask any provider for the written scope, deliverables and timeline before accepting a quote for your exit
