Airtable to Postgres sync after migration: what we are building next

If you have read about AT Migrator anywhere else, you have probably seen it described as a one-time, one-way cutover tool with no ongoing sync. That is an accurate description of what ships today. It is not where we are stopping. We are building sync: after your base has been migrated, the records still landing in Airtable can keep flowing into your PostgreSQL database until you are fully off Airtable. Here is what it will do, what it will not do, and where it stands.

Where the “no sync” impression comes from

We built the cutover first and priced it once, because that is the job most teams hire us for: leave Airtable, own your data, stop paying per seat. Every write-up that calls AT Migrator a one-way, one-time tool is reading the product correctly.

The gap is that teams rarely move in one clean jump. Two patterns come up constantly:

• The database is ready before the front end is. You migrate on a Tuesday; the app that reads Postgres is six weeks out. Airtable keeps collecting rows the whole time.
• The freeze was not clean. A few hundred records got created in Airtable after the final export, during the cutover weekend.

What sync will do

Two things.

Pick up only what changed. Records created or edited in Airtable since the last run. New rows insert, existing rows update in place. Everything else is left alone.

Run on a schedule. You set how often it checks, and it runs in the background, within Airtable's rate limit, so your existing automations keep working. Which frequencies we offer is one of the things we are still deciding.

The important part: it writes into the database your migration already built. Same tables, same foreign keys from your linked records, same SQL views for formulas and rollups. It is not a second, parallel copy of your base sitting next to the real one.

What it will not do, at least not first

It will not be two-way. Edits made in Postgres will not be written back into Airtable. Two-way sync means conflict rules for every field: which side wins when both change the same record. Getting that subtly wrong is how people lose data quietly. The transition case only needs one direction anyway. Airtable is still where people type, Postgres is where things get read.

It will not be real time. Airtable allows five API requests per second per base, shared with your own automations. Sync will be scheduled and polite. Think minutes, not milliseconds.

It is not a reason to stay on Airtable forever. This is built for the transition window: the weeks or months between the migration and the day nobody opens the base any more. If you want to keep it running longer, you can; that is what a subscription is for.

Pricing: a subscription, and we are still deciding

Migrations stay a one-time payment tied to one base. That does not change.

Sync is a different shape of product. It keeps running, keeps polling Airtable, keeps writing to your database, so it will be a monthly subscription that you cancel the day you are fully off Airtable. What we have not settled is how it is metered.

We would rather settle that with the people who will actually pay for it than guess in private. If you have a view, it counts.

What we would like to ask you

None of these have a settled answer yet, and we would rather hear yours than guess. They are short questions, and your answers change what gets built first:

• How often would you want Postgres updated: once a day, every hour, or only when you ask for it?
• If someone deletes a record in Airtable after the migration, should it be deleted in Postgres too?
• Will anyone be editing data directly in Postgres while your team is still working in Airtable?
• How long do you expect to keep using Airtable after the migration: a few weeks, or a few months?

If you have answers, we would genuinely like to hear them. Book a short call or email us and tell us what your transition looks like. That is the fastest way to get your setup into the design, and the teams who do it hear first when sync ships.