Airtable and Postgres: the path designed from day one

Here is the thesis, open to refutation: Airtable's published API limits are not constraints to endure — they are architecture specifications. Read correctly, they describe the system to build: an operational layer where the business works — Airtable — and a scale layer where volume and applications live — Postgres, in our case via Supabase. The pipeline between the two is not an emergency exit improvised under pressure. It is a component you design on day one, just like the data schema.

This hybrid architecture rests on a clean division of roles. Airtable excels at what it was built for: interfaces the business can edit, views, automations, extensions — the team stays autonomous in its own tool, in real time. Postgres excels at what it was built for: arbitrary SQL, volume, per-tenant isolation, concurrent access from web applications. "Every Supabase project gets a full Postgres database," Supabase writes: not an abstraction — the full engine.

The rest of this article documents that API contract, the four pipeline patterns, and the proof in production.

Here is what Airtable's official pages publish as of August 12, 2026:

The most important line is not in this table: it is one sentence from the rate-limits documentation. "If you anticipate a higher read volume, we recommend using a caching proxy." The vendor itself designates the external read layer as the intended pattern. Using Airtable as the backend for high-traffic Next.js applications means building precisely that proxy — and building it in Postgres rather than an ephemeral cache, gaining joins, aggregations and row-level security along the way.

This is the reasoning at the heart of how we build: read a platform's published limits as specs, and design with them rather than against them.

1. Scheduled replication. The PostgreSQL documentation describes logical replication as a publish/subscribe model: initial snapshot, then an incremental stream based on a replica identity. Airtable does not expose a transaction log; the equivalent is a scheduled task that reads changes and upserts them into Postgres. Two orchestrators fill that role: pg_cron on the Supabase side, or Trigger.dev scheduled tasks with deduplication.

2. Source of truth per domain. Flow direction is a per-table decision, not a religion. Contacts belong to Airtable and replicate into Postgres; application events are born in Postgres and flow back as aggregates. Supabase even publishes an Airtable foreign data wrapper — tables can be queried in SQL, read-only and without filter pushdown: ideal for exploration, and one more argument for scheduled replication in production.

3. Stable IDs. The Airtable record ID ("rec…") is immutable — it "cannot be altered in any way." Stored as an external key in Postgres, it makes every upsert idempotent. In the other direction, the write API supports native upsert:

{
  "performUpsert": { "fieldsToMergeOn": ["external_id"] },
  "records": [{ "fields": { "external_id": "crm-4812", "status": "active" } }]
}

Zero matches creates, exactly one updates, several fail the request. Idempotency is wired in both directions.

4. Portable schema conventions. Pagination by 100, field types, computed fields excluded from merge: everything demands an explicit mapping between the two layers. That mapping is a deliverable in its own right — we explained why in the schema is the deliverable. In our projects, it is stored as configuration inside Airtable itself: the business sees and governs what gets synced.

The classic objection: "what about latency?" It assumes everything must be real time. But the business already works in real time, inside Airtable. Only the read layer is concerned, and its freshness is tuned per domain.

Three documented mechanisms combine. Airtable webhooks send a minimal ping; the actual content is fetched with a separate call, delivered at-least-once with up to 13 retries over roughly a day — and a refresh to automate, since a webhook expires after 7 days without one. Scheduled replication sets the baseline rhythm: hourly for a reference table, daily for history. On the application side, Next.js ISR drives revalidation: revalidate = 60 for hot content, revalidatePath on demand right after the pipeline writes; if a revalidation fails, the last generated version keeps being served.

For perspective: classic CDC captures changes from the transaction log, in order, at-least-once. Webhooks and scheduled replication play that role here, with the same requirement of idempotent writes: duplicate deliveries are normal.

What doing nothing costs — An application wired directly to the API shares the base's 5 req/s with every existing automation; each traffic spike is paid in 429 statuses and 30-second waits. On the Team plan, the 100,000 monthly call quota gets burned on redundant reads, after which all traffic is slowed to 2 req/s until the 1st of the month. And when the base approaches 50,000 records, the scale layer gets built in a rush — at the worst possible moment.

We operate this model. Eight production applications on Next.js + Supabase + Vercel — SaaS products, portals, dashboards — are fed by this kind of pipeline, across more than thirty delivered projects (Ownward internal data, 2026).

The pipeline is a mapping-driven sync engine: Python orchestrated on Trigger.dev, with its configuration stored in Airtable. It connects six CRM/ERP systems — HubSpot, Oscar, Dynamics 365, Hyperplanning, YPAREO over SOAP, and Airtable — to a single reference database. A new source means a new mapping, not new code; and zero manual re-entry. The choice of orchestrator follows the five criteria detailed in when to industrialize an automation.

And Airtable in all this? It remains the layer where the business is at home. In one year, we built seventeen custom extensions there with the official SDK (standard JavaScript/React), including a full CRM with telephony, templated emails and interactive maps. Adoption was immediate, precisely because the team never left its tool (Ownward internal data, 2026).

Our starting grid: it gets debated domain by domain, but it prevents the default decision — everything in a single layer.

Right-hand column, always the same requirement: a stable key (rec ID or external key), upsert writes, duplicate-free recovery.

This architecture has a fixed cost: a pipeline is software, with monitoring, error recovery and maintenance. Below a certain scale — one base, no external application, low read volume — Airtable alone is enough, and that is perfectly fine. Coexistence also introduces a deliberate replication delay: cases requiring strong read consistency are handled domain by domain, sometimes by reading the source directly. Finally, two layers means two models to keep aligned; without an explicit, versioned mapping, schema drift is a matter of months. None of this argues against the pattern — it is its price, and it can be budgeted.