How to verify Airtable formula migration with our SQL showcase

Scale is one proof. Formula fidelity is another. This guide walks through AT Migrator's complex-formula showcase: download the SQL seed, understand how nested Airtable formulas land in vt_ views, then compare computed values the same way you would on a production cutover.

Step 1 — Open the formula showcase base

The public base is read-only. Browse Projects and Tasks — including nested formula fields — the same way you would in your own workspace.

Open the formula showcase Airtable base →

Step 2 — Download the formula showcase SQL

Start with the artifact. The seed is a compact AT Migrator schema export (tables + views — no multi-gigabyte COPY dump). Import it into any Postgres host, then inspect the formula logic.

Download at-migrator-complex-formula-showcase-migration.sql →

Step 3 — Import into Postgres

# Neon / remote
psql '<connection-string>' -f at-migrator-complex-formula-showcase-migration.sql

# Local
createdb formula_showcase
psql formula_showcase -f at-migrator-complex-formula-showcase-migration.sql

After import, list views: SELECT table_name FROM information_schema.views WHERE table_schema = 'public'; — you should see vt_projects and vt_tasks.

Step 4 — Understand the mapping

Airtable formula, rollup, and lookup fields recalculate when underlying data changes. AT Migrator does not freeze those values as static columns in the base tables. Each table gets a companion view named vt_[table] that mirrors the Airtable grid: stored columns plus computed fields rebuilt as SQL.

• Base tables — source fields (names, dates, numbers, status, FK from tasks → projects via _at_id).
• vt_projects — live formulas: days_remaining, project_duration_business_days, status_flag, budget_variance, weighted_project_score, dynamic_summary_text.
• vt_tasks — live formulas: business_days_until_deadline, overdue_days, task_tier, completion_score, risk_level, formatted_status_message.

Step 5 — Compare project formulas

Insert or migrate a project row, then query the view. Match each field against the same record in Airtable:

SELECT
  _at_id,
  project_name,
  completion_percentage,
  due_date,
  days_remaining,            -- date math vs CURRENT_DATE
  status_flag,               -- Completed / Overdue / At Risk / On Track
  budget_variance,           -- spend vs budget
  weighted_project_score,    -- priority × progress × budget health
  dynamic_summary_text
FROM public.vt_projects
WHERE _at_id = '<airtable-record-id>'
LIMIT 1;

What each field proves:

• days_remaining — date arithmetic against CURRENT_DATE (not a frozen number).
• status_flag — nested IF logic: Completed / Overdue / At Risk / On Track from completion % and due date.
• budget_variance — spend vs budget ratio as live SQL.
• weighted_project_score — priority weighting × progress × budget health.
• dynamic_summary_text — concatenated status string rebuilt from the same inputs.

Step 6 — Compare task formulas

SELECT
  _at_id,
  task_name,
  status,
  effort_hours,
  difficulty_rating,
  overdue_days,
  task_tier,
  completion_score,
  risk_level,                -- High / Medium / Low from nested IF
  formatted_status_message
FROM public.vt_tasks
WHERE _at_id = '<airtable-record-id>'
LIMIT 1;

risk_level and completion_score use nested conditions on effort, difficulty, and dependencies — the kind of Airtable formula that CSV exports and sync tools flatten into a static string. If the view matches Airtable for a few spot-checked tasks, the translation is working.

How this pairs with the 48k CRM sample

Use both samples when evaluating AT Migrator:

• CRM sample (48,000+ records) — volume, junction tables, attachments, rollups, and a full pg_dump.
• This formula showcase — nested IF / date / score logic in vt_* views without the noise of tens of thousands of rows.

Together they answer the two questions buyers ask most: “Will my data arrive intact at scale?” and “Will my formulas still recalculate in Postgres?”

Ready for your own base?

See the full migration playbook, or view pricing when you are ready to run AT Migrator on your schema.