Migrating 50,000 Airtable records to Postgres in 15 minutes

A base with 50,000 records used to be an all-day migration if those records carried attachments. It is not anymore. We rebuilt how AT Migrator runs a migration: the row data now lands in PostgreSQL in about 15 minutes, and attachment files copy to your storage afterward in a separate pass. Here is what changed and why.

How it used to work

Every migration ran as a single pass. For each record, AT Migrator would download that record's attachments from Airtable's CDN, upload them to your bucket, and only then write the row to Postgres. Rows waited on files.

That is fine for a 500-row base. On a base with tens of thousands of rows and an attachment on most of them, it fell over. Files were copied roughly two at a time for the entire run, and Airtable's signed file URLs expire after about two hours, so a long migration would start racing its own links.

We had an internal test base of around 25,000 records with a file on nearly every row. It was on track to take the better part of a day, and the row data was stuck behind the files the whole time.

What we changed

We split the migration into two phases.

First, the row data. All of it goes in before any file is touched: larger insert batches, more records transformed in parallel, and the schema, linked records, and formulas rebuilt as it runs. For the 50k base this phase finished in about 15 minutes.

Then, attachments. A dedicated phase walks the rows that are already in Postgres, re-reads Airtable for fresh file links so nothing has expired, and copies files into your storage many at a time, with retries. It updates each row's file references in place as it goes. Large files stream instead of buffering, so memory stays flat.

The practical result: your Postgres database is usable within minutes of starting, and the files fill in behind it. You can watch that second phase run, with a rough time remaining.

The 50,000-record test

We ran a real base end to end: 50,000 records with attachments, migrating to PostgreSQL.

• Row data: about 15 to 16 minutes. Every table live and queryable in Postgres at that point.
• Attachments: copied afterward, in the background, into the customer's own storage, with progress and an estimate shown the whole time.
• Data loss: none. If a file fails to copy after retries it keeps a working reference and gets flagged, so you can retry just those files without re-running the migration.

Try it on your base

If you have a large Airtable base, especially one with a lot of attachments, that you have been putting off moving, now is a good time. Start with a migration plan or book a discovery call and we will scope records, attachments, and formula risk first. There is also a live estimator on the home page that will size the migration window for your record and attachment counts.