# Airbyte vs AT Migrator: Pipeline or Migration for Airtable to PostgreSQL?

Airbyte and AT Migrator can both put Airtable data into PostgreSQL, but they are built for different jobs. Airbyte is a general data pipeline: it copies data from hundreds of sources into a destination on a schedule. AT Migrator is a dedicated migration tool: it moves an Airtable base into Postgres and leaves you with a database that runs on its own. What decides which one you need is what lands in Postgres: real foreign keys, SQL logic, and files, or arrays of record IDs, stored values, and text.

## Key takeaways
- Airbyte brings Airtable formulas, rollups, and lookups across as values: a string, a number, or an array. Nothing converts them to SQL, so the logic that produced them stays behind in Airtable. AT Migrator translates them into SQL expressions, joins, and aggregates.
- Linked records arrive in Airbyte as arrays of record IDs, and its Postgres destination does not define foreign keys or relationships. AT Migrator reads each link's cardinality and builds foreign keys or junction tables.
- Airbyte's Airtable source supports full refresh only, with no incremental sync, so every run reads the whole base again under Airtable's 5 requests per second cap. AT Migrator reads one table at a time, resumes an interrupted run, and emails you when it is done.
- Airbyte is a pipeline you run yourself or subscribe to, built to keep running. AT Migrator is a one-time payment for a migration that ends.

## What each tool is
Airbyte is an open-source data integration platform, available self-hosted or as a managed cloud service. It has a large catalogue of source connectors, Airtable among them, and over fifty destinations, and it runs them as scheduled syncs. That makes it a good fit for teams that already run a data stack and want Airtable data in a warehouse for reporting. AT Migrator is a dedicated migration product: moving an Airtable base into PostgreSQL, structure and logic included, is the whole product, not one connector among many.

## Does Airbyte turn Airtable formulas, rollups, and lookups into SQL?
**No. Airbyte copies the result of a formula, rollup, or lookup as a value, and nothing in Postgres recalculates it.** Its Airtable connector maps a formula to a string, a number, or an array depending on what it returns, and maps lookups and rollups to arrays. Those arrays land in Postgres as JSONB columns. The connector's documentation describes data types and nothing else on this topic, with no mention of formula logic being carried across, so the answer is no. A tool that had solved that problem would say so.

The practical effect is the same as with any copy. The value is right on the day of the sync. Change an input in Postgres and the total next to it does not move. Switch Airtable off and the columns freeze at their last value. AT Migrator treats this as the core of the job. Formulas are translated into SQL expressions, so a value that used to be computed by Airtable is computed the same way by Postgres. Rollups and lookups are recreated as joins and aggregate queries that read from the new foreign keys, rather than a stored snapshot.

> What makes a migration complete: Formulas, rollups, and lookups are where the business rules in an Airtable base live. A tool that carries across the values but not the rules has copied the data and left the working part of the base behind.

## Does Airbyte turn linked records into foreign keys and junction tables?
**No. Linked records arrive as arrays of record IDs, and Airbyte does not create relationships between tables.** The connector maps a linked record field to an array of strings, which are the IDs of the records on the other side. Airbyte's Postgres destination writes each Airtable table as its own table, stores arrays and nested objects as JSONB, and says nothing about foreign keys or relationships. So the links are there as IDs, but it is up to you to write the joins, or to build the foreign key columns and junction tables yourself and fill them from those arrays.

AT Migrator does that design work for you. It reads the setting Airtable stores on each side of a link field for whether that side allows one record or many, and maps the relationship accordingly: one-to-many becomes a foreign key column, many-to-many becomes a junction table.

## Do attachments end up as usable files?
**Not as files. Airbyte stores an attachment as a string in the row, and the file itself stays in Airtable.** The connector maps attachment fields to a string value, and nothing in its documentation copies the files to a storage location you control. Since Airtable file links expire, a database that only holds those links will eventually point at files that no longer load. AT Migrator copies attachments to your own S3-compatible bucket and stores each file's URL, name, and size alongside the row it belongs to. If a file fails to copy, only that file is retried on a re-run.

## How does it behave on a large base?
**Airbyte's Airtable source only does full refreshes, so every sync reads the whole base again.** The connector supports full refresh in overwrite or append mode and does not support incremental sync. Airtable limits every tool to 5 requests per second per base, so on a large base each scheduled run spends its time re-reading data that has not changed. In fairness, the connector handles the limit well: it backs off and retries when Airtable returns a rate-limit error. It is also tied to the schema it discovered. If you rename a table, it stops syncing until you reset and reselect the schema.

AT Migrator reads Airtable one table at a time and retries automatically when it hits the rate limit. A migration keeps running after you close the tab, shows which step is running and how many rows have moved, and emails you the status when it finishes. If it is interrupted, it resumes from where it stopped: tables already finished are skipped, and a partly-read table picks up where it left off.

## How does the cost model differ?
**Airbyte is a pipeline platform you run or subscribe to. AT Migrator is a one-time payment for the migration.** Airbyte can be self-hosted, which means no licence fee but a system for you to deploy and keep running, or used as a managed cloud service, where plans are metered by data volume or by the compute capacity you reserve. Both are built for pipelines that run continuously, and each scheduled sync keeps calling Airtable, which meters API use by plan. That is the right shape for reporting on live data. A migration is a different shape of job: it has a start and an end. AT Migrator is priced once for the move, and when it finishes you are not left with a pipeline to maintain or a subscription to cancel.

## What about setup?
This part is worth knowing but should not decide much on its own. With Airbyte you configure a source, a destination, and a connection between them, then decide how the destination tables should look. Airbyte also adds its own metadata columns to every table it writes, and replaces special characters in table and column names with underscores. AT Migrator authenticates over OAuth or a personal access token, reads every table and field in your base automatically, and connects to Postgres over a standard TLS connection string.

## Which one fits your situation
- **You are leaving Airtable and the base has linked records, rollups, lookups, or formulas:** AT Migrator builds foreign keys and junction tables and recreates the logic as SQL. Airbyte gives you ID arrays and values to work from.
- **Your files need to survive after Airtable is gone:** AT Migrator copies them to your own bucket.
- **A large base, or one you cannot guarantee will finish uninterrupted:** AT Migrator resumes an interrupted run instead of re-reading everything.
- **Airtable stays in use and you want its data in a warehouse for reporting:** Airbyte is a strong fit, especially if you already run it for other sources.

## FAQ
**Does Airbyte convert Airtable formulas, rollups, or lookups to SQL?** No. Airbyte's Airtable connector maps them to strings, numbers, or arrays and copies the values. In Postgres they are stored columns or JSONB, and nothing recalculates them. AT Migrator translates formulas into SQL expressions and recreates rollups and lookups as joins and aggregate queries.

**Does Airbyte create foreign keys for Airtable linked records?** No. Linked records arrive as arrays of record IDs, and Airbyte's Postgres destination does not define foreign keys or relationships. AT Migrator maps one-to-many links to foreign keys and many-to-many links to junction tables.

**Does Airbyte copy Airtable attachments?** It stores each attachment as a string in the row. The files stay in Airtable, whose links expire. AT Migrator copies files to your own S3-compatible bucket.

**Does Airbyte's Airtable connector support incremental sync?** No. It supports full refresh in overwrite and append modes only, so each sync reads the whole base again.

**What happens if I rename a table in Airtable when using Airbyte?** The renamed table stops syncing until you reset the source schema and reselect it.

**What does Airbyte add to my Postgres tables?** Metadata columns for its own tracking, such as an extraction timestamp and sync metadata. Nested objects and arrays are stored as JSONB, and special characters in table and column names become underscores.

**How does Airbyte's cost model compare to AT Migrator's?** Airbyte is a pipeline platform that is self-hosted or paid for as a managed service, built to run continuously. AT Migrator is a one-time payment for the migration, with nothing to maintain after it finishes.

**When is Airbyte the better choice?** When Airtable stays in use and you want its data in a warehouse for reporting, especially if you already run Airbyte for other sources.

---
*Considering a migration? Book a free discovery call with AT Migrator: https://www.atmigrator.com*