# 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.

## Key takeaways

- Today AT Migrator is a one-time migration. Sync is not in the product yet, so nothing on this page is available right now.
- We are building one-way sync from Airtable into the Postgres database your migration already created, for the records that keep landing in Airtable while you finish moving off it.
- It runs on a schedule and picks up only what changed, into the same schema, foreign keys, and SQL views the migration produced.
- Two-way sync, which would write Postgres edits back into Airtable, is not part of the first version.
- Sync will be a subscription, separate from the one-time migration price. The amount is not fixed yet, and that is the honest answer.
- We are designing it now. If you need it, tell us what your setup requires; it changes what we build first.

## 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.

| | Migration (today) | Sync (in design) |
|---|---|---|
| What it moves | The whole base: schema, rows, relationships, formulas, attachments | Only records added or changed since the last run |
| Direction | Airtable → Postgres, once | Airtable → Postgres, repeatedly |
| When it runs | When you start it | On a schedule you set |
| Schema | Creates it | Writes into the one the migration created |
| Price | One-time, per migration | Monthly subscription, amount not set |
| Status | Shipped | In design and development |

Sync continues a migration you have already run. It does not replace it.

## 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.

> **Nothing on this page is live yet.** Sync is in design and development. It is not in the product today and we are not publishing a ship date we cannot stand behind. When it ships, this post gets updated to describe what actually shipped. If you are evaluating AT Migrator right now, evaluate the one-time migration on its own merits and treat sync as something to talk to us about.

## 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 at https://www.atmigrator.com/contact 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.