# Baserow vs AT Migrator: Moving Airtable Into an App or Into PostgreSQL Baserow and AT Migrator both get an Airtable base out of Airtable, but they put it in different places. Baserow imports it into Baserow, an open-source no-code database app, and leaves out every formula, lookup, and rollup. Its data does sit in PostgreSQL, but in a layout that belongs to Baserow. AT Migrator moves the base into a PostgreSQL database that belongs to you, with those fields rebuilt as SQL. So the choice is between an interface on top of your data and owning the data itself. ## Key takeaways - Baserow's Airtable import leaves out every formula, lookup, and rollup, along with their values. Its own import code says formula conversion is not supported yet. AT Migrator translates formulas into SQL and recreates rollups and lookups as joins and aggregates. - You can rebuild each calculated field by hand in Baserow, but Baserow does not keep the original formula, so save your own copy before you import. Some Airtable behaviour has no exact equivalent. - The PostgreSQL underneath Baserow is Baserow's, not yours: tables named database_table_ plus an ID, columns named field_ plus an ID, field names and formulas kept in its metadata, and no direct database access at all on Baserow Cloud. Building your own application on it means learning that layout or going through Baserow's API. AT Migrator builds a schema named after your data, with foreign keys and SQL logic, that any application can use. - Links arrive as Baserow link fields, and a link that allowed one record is reported as downgraded. A base with many large files has needed a manual import. AT Migrator maps links by cardinality, resumes an interrupted run, and copies files to your own bucket. ## What each tool is Baserow is an open-source platform for building databases through a spreadsheet-style interface, with views, forms, automations, and an API. You can self-host it or use its cloud service, and it has an Airtable import for people switching over. AT Migrator is a dedicated migration product: moving an Airtable base into PostgreSQL, structure and logic included, is the whole product, not one import option among many. ## Does Baserow import Airtable formulas, rollups, or lookups? **No. Baserow leaves them out, and their values go with them.** When Baserow imports a base, it carries over everything that is stored: records, text, numbers, dates, links, and files. It does not carry over anything Airtable calculates. Those fields are not created in Baserow at all, so their values never arrive, and the import report only notes that they were not supported. This is not an old gap. Baserow's own import code says formula conversion is not supported yet, and it was last changed in August 2026. The only calculated fields that come across are created-time and last-modified-time. In practice, every formula, lookup, and rollup column is missing after the import, and Baserow does not keep a copy of how they were written, so save your formulas from Airtable before you start. You can rebuild them in Baserow, which has its own formula, lookup, and rollup fields, but you write each one again by hand and check it against Airtable yourself. The two formula languages are not identical, so a rebuilt formula is not always an exact copy. Baserow's own tip is to turn those fields into plain text or number columns in Airtable before importing, so the values come across. That keeps the numbers as they were that day, and nothing updates them afterwards. Do it on a copy of your base, because it erases the formulas. AT Migrator translates Airtable formulas 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. > What makes a migration complete: Formulas, rollups, and lookups are where the business rules in an Airtable base live. An import that leaves them out has moved the data and left the rules behind, however well the rest of it goes. ## Does Baserow keep linked records as real relationships? **Partly. Links come across as Baserow link fields, but they lose their cardinality.** Baserow turns Airtable links into its link-to-table fields. For a link that allowed only one record on a side, its import report says support for a one-to-many relationship was dropped. Baserow can limit a link field to a single row, but that is a setting inside Baserow, not a foreign key in the database. AT Migrator 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. ## Is the PostgreSQL database underneath something you can build on? **Not comfortably. It is PostgreSQL, but the layout belongs to Baserow, and a custom application built on it starts with learning that layout.** Every user table is named database_table_ plus an ID, and every column field_ plus an ID. A Baserow engineer explained in a 2023 community thread that this avoids an ALTER TABLE each time someone renames a field, and keeps a field called id or order from clashing with the internal columns Baserow adds. Those exist on every row: a decimal order value, and a trashed flag, so deleted rows can still be sitting in the table. Links live in separate relation tables. The names, types, and formulas of your fields are kept in Baserow's metadata tables, so reading one table properly means joining to them, and the same thread says there is no readable view in the core and suggests writing your own. Baserow's team says it usually recommends the API for technical integrations, because the schema changes at runtime whenever someone edits a table's structure, and another reply in that thread warns that editing the tables directly can cause inconsistency. On Baserow Cloud you cannot reach the database at all, because customers share one, so your data is reachable only through the REST API. Self-hosting gives you the database, with the layout above. All of this is reasonable for an app that manages thousands of people's tables. It makes a poor foundation for your own product: a backend, a reporting layer, or an internal tool built on it ends up tied to Baserow's naming and rules, or sits behind its API. Those threads are from 2023, but the naming and the internal columns are all in the current source. AT Migrator builds tables named after your Airtable tables and columns, keeps each record's Airtable ID in its own column, and uses real foreign keys, junction tables, and SQL for the logic. Any application, BI tool, or ORM can connect to that database, with or without an interface in front of it. ## How does it behave on a large base or with big files? **Fine for a modest base. A large one with many files has needed a manual import.** Baserow downloads each attachment from Airtable and uploads it again. It states no row limit, but a 2024 community thread shows where the practical limit sits: a user with about 130,000 rows and 70 GB of attachments found the default import timed out, and Baserow staff said a manual command-line import was needed. AT Migrator copies attachments to your own S3-compatible bucket and stores each file's URL, name, and size alongside the row, and if a file fails to copy, only that file is retried on a re-run. It reads Airtable one table at a time, retries automatically when it hits Airtable's limit of 5 requests per second per base, and resumes an interrupted run from where it stopped. ## How does the cost model differ? **Baserow is software you run or subscribe to. AT Migrator is a one-time payment for the migration.** Baserow can be self-hosted, which means you run and maintain it, or used as a cloud service with per-user plans and limits on rows, storage, and automation credits. That suits a tool your team works in every day. A migration has a start and an end, and AT Migrator is priced once for the move. When it finishes, you have a PostgreSQL database and no subscription attached to it. ## What about setup? This part is worth knowing but should not decide much on its own. Baserow's import needs a public share link to the whole Airtable base, and if the base requires authentication it asks you to copy two Airtable session cookie values from your browser. 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 formulas, rollups, lookups, or one-to-many links:** AT Migrator translates formulas to SQL and maps links by cardinality. Baserow leaves every calculated field to rebuild by hand. - **You want a table-style interface on top of your data, and the base is mostly stored data:** Baserow is a good option for that, and its import brings the data over cleanly. - **You want to own the data, and leave room to build your own application or switch tools later:** AT Migrator gives you a clean PostgreSQL schema you control. Baserow ties that freedom to its own layout. - **You want both a database you own and an interface for your team:** migrate with AT Migrator, then bring the tables into Baserow with its PostgreSQL data sync, which mirrors a table from your database into Baserow. - **A large base, or one with many large files:** AT Migrator resumes an interrupted run and emails you the status when it finishes. ## FAQ **Does Baserow import Airtable formulas, lookups, or rollups?** No. Baserow's import leaves them out, along with their values. Only created-time and last-modified-time fields are converted. AT Migrator translates formulas into SQL expressions. **Is that a current limitation or an old one?** Current. Baserow's import code says formula conversion is not supported yet, and it was last changed in August 2026. **Can I recreate my Airtable formulas in Baserow?** Mostly, by hand. Baserow has its own formula, lookup, and rollup fields, but you rewrite each one and check it against Airtable. A few Airtable behaviours have no exact equivalent. **How do I keep the data from my Airtable formulas if I import into Baserow?** Change those fields to text or number fields in Airtable before importing, on a duplicate of the base. You keep the values as they stand that day, but nothing recalculates them, and the formulas are lost. **Does Baserow keep Airtable one-to-many links?** It imports links as link-to-table fields, but for a link that allowed one record, its import report says support for a one-to-many relationship was dropped. AT Migrator maps one-to-many links to foreign keys and many-to-many links to junction tables. **Is Baserow's data stored in PostgreSQL?** Yes, but in Baserow's own layout. Tables are named database_table_ plus an ID, columns are named field_ plus an ID, and field names and formulas are kept in metadata tables. AT Migrator creates tables and columns named after your Airtable base. **Can I build my own application on the PostgreSQL database behind Baserow?** It is difficult. The schema is Baserow's, it changes at runtime when someone edits a table, and Baserow's team recommends the API for technical integrations. On Baserow Cloud there is no direct database access at all. With AT Migrator you get a clean schema with foreign keys that any application can use. **Can Baserow import a very large Airtable base?** It states no row limit, but a 2024 community thread describes a base with about 70 GB of attachments timing out and needing a manual command-line import. **Can I use Baserow on top of a PostgreSQL database AT Migrator created?** Yes. Baserow has a PostgreSQL data sync that mirrors a table from your database into Baserow, so you can migrate with AT Migrator and give your team a spreadsheet-style interface over the result. **How does Baserow's cost model compare to AT Migrator's?** Baserow is software you self-host or pay for per user on its cloud plans, with limits on rows and storage by plan. AT Migrator is a one-time payment for the migration, with nothing to maintain after it finishes. --- *Considering a migration? Book a free discovery call with AT Migrator: https://www.atmigrator.com*