Airtable vs PostgreSQL: When the Spreadsheet Becomes a Liability

Verdict up front: Airtable is the right tool until it isn't. The migration trigger is usually one of: 50k+ rows in a single table, more than 3 chained API calls per user action, or an automation that takes 30+ seconds to run. If you hit any of these, plan migration within 6 months — every month you stay costs you more in workarounds.

Airtable's real pricing in 2026

• Free: 1,000 records/base, 100 automation runs/month, 1GB attachments
• Team: €20/seat/month, 50k records/base, 25k automation runs
• Business: €45/seat/month, 125k records/base, 100k automation runs, SSO
• Enterprise: Custom, 500k records/base, audit logs

Postgres equivalent costs:

• Self-hosted Postgres on DO droplet: €12/month for 1GB RAM, fits ~5M rows comfortably
• Supabase Free: €0, 500MB
• Supabase Pro: €25/month flat, 8GB DB
• AWS RDS db.t4g.medium: €98/month, multi-AZ HA

For 10 seats on Airtable Team: €200/month for 50k rows. For €25/month on Supabase Pro: 8M+ rows. The pricing gap at scale is enormous — but you're paying for Airtable's UI, which is the real product.

Row limit triggers

What happens at different row counts:

• <5k rows: Airtable is fast, no issues
• 5k-30k rows: Views with complex filters start to lag; rollup formulas slow down
• 30k-50k rows: Linked record lookups visibly slow; API calls timeout occasionally
• 50k-125k rows: Plus tier full; on Pro/Business; UI delays of 2-5 seconds common
• >125k rows: Business tier full; Enterprise required; operations getting painful

Postgres handles 10M rows on a €12/month droplet without breaking a sweat, assuming proper indexes.

Query performance at 100k rows

Simple lookup ("find row where status = 'open'"):

• Airtable: 1-3 seconds (no index, scans all rows)
• Postgres with index: <5ms

Aggregation ("count rows by status, grouped"):

• Airtable: 3-8 seconds for rollup formulas, longer with view filters
• Postgres: <50ms with proper indexing

Join across 3 tables ("show me orders + customer name + product name"):

• Airtable: requires linked records + lookup fields, can take 5-15 seconds to render
• Postgres: SQL JOIN, <100ms

For interactive use (users waiting for results), Airtable becomes unpleasant past 30k rows. Postgres stays interactive into millions.

API rate limits

Airtable API: 5 requests/second per base. Hit this and you get HTTP 429 — your app degrades for 30 seconds.

Postgres: practical limit is connection pool capacity (PgBouncer can handle 10k+ req/sec on modest hardware). Effectively unlimited for normal app use.

The Airtable rate limit is the most common reason we've helped teams migrate. Their app got more popular, started hitting 5 req/sec, started returning errors to users.

When Airtable is right

• Non-developer team needs a CRUD interface today
• <10k records expected for the foreseeable future
• The UI IS the product (not an app on top of the data)
• 5-15 seats max
• Internal tool, not customer-facing

When to migrate to Postgres

• 50k+ records or growing 20%+ year-over-year
• You're building a customer-facing app on top of the data
• You need joins or complex queries Airtable can't model
• You're hitting 5 req/sec API rate limits
• Airtable Business pricing (€45/seat) is becoming painful at your seat count
• You need audit logs, version history, or compliance Airtable can't provide

The hybrid pattern

For teams not ready to fully migrate: Postgres as the source of truth + Airtable synced as a view for ops/marketing teams.

• Production app writes to Postgres
• Cron job (every 5-15 min) syncs relevant tables to Airtable via the API
• Ops team uses Airtable views, filters, automations
• Changes in Airtable get synced back to Postgres (or are read-only)

This lets you scale the app without losing the team's familiar workflow. Trade-off: data is eventually consistent, not real-time.

Migration roadmap

Typical 30-table Airtable base → Postgres migration:

1. Week 1: Schema mapping. Airtable's loose schema → Postgres strict schema. Decide column types, normalise linked records into foreign keys.
2. Week 2: Data export (Airtable CSV export per table) + import (psql COPY). Cleanup messy data.
3. Week 3: Rebuild views and automations. Postgres views, materialized views, or Supabase Edge Functions.
4. Week 4: New frontend. Either custom (Next.js + Supabase) or Retool / NocoDB / Outerbase as a no-code-style UI on top of Postgres.

Total: 3-5 weeks, €12k-€20k. Pays back in 6-18 months depending on Airtable seat count.