Airtable, Notion, or Postgres? Pick the Right Data Layer
Airtable, Notion, or Postgres? Pick the Right Data Layer
The Decision Framework
Every solo builder faces this choice: Airtable, Notion, or Postgres for their automation data layer. Most comparisons focus on features and interfaces. Jordan cuts through the noise with a three-axis framework:
1. Throughput ceiling - How many requests per second before the API rejects you?
2. Concurrency safety - Can you write to the same record from multiple places without corruption?
3. Cost at volume - What does it actually cost when your automations scale?
Airtable: Lightweight Relational Ops
Rate Limits:
• 5 requests per second per base
• 50 requests per second aggregate across all bases per token
• Exceed either limit → HTTP 429 with 30-second backoff
Optimization Strategies:
• Batch up to 10 records per write request (effective throughput: ~50 records/second)
• Use performUpsert parameter for find/create/update in single call
• Leverage Sync API on Business/Enterprise (10k rows per request, 20 requests per 5 minutes per base)
Monthly Caps:
• Free: 1,000 calls/month
• Team: 100,000 calls/month ($20/user/month)
• Business: "High" limit ($45/user/month)
Sweet Spot: CRM tables, project trackers, client pipelines with moderate API usage
Notion: The Docs-Adjacent Database
Rate Limits:
• 3 requests per second average per integration (despite rumors of 5 rps)
• Bursts allowed, but sustained usage above 3 rps triggers 429s
Payload Constraints:
• 500KB max per request
• 1,000 block elements max per request
• 100 items max for relation/multi-select updates
• 100 rows max per database query page
Sweet Spot: Client project wikis, knowledge bases where content is the value and database is just the index
Limitation: Pushing rich pages requires 2-3 API calls per record, dropping effective throughput to ~1 record/second
Postgres on Supabase: When You Need the Real Thing
Key Advantages:
• Transactions: Atomic UPSERT (INSERT ON CONFLICT) for idempotent writes
• True Concurrency: Multiple webhook events can hit the same table simultaneously without corruption
• Connection Scaling: Micro (60 direct/200 pooled) to 16XL (500 direct/12,000 pooled)
Cost Structure:
• Supabase Pro: $25/month per org (includes $10 compute credits)
• Micro compute: ~$10/month
• Net cost: $25/month for fully managed Postgres (only $5 more than Airtable Team)
Use Cases:
• Stripe webhook ledgers
• Event processing requiring atomic writes
• High-frequency sync jobs
• Any workload needing real transactions
The Bright Line Decision Rules
Stay on Airtable if:
• Under 5 requests/second per base
• Under 100k API calls/month (Team plan)
• Can batch writes effectively
• Don't need atomic transactions
Stay on Notion if:
• API usage is light sync (few summaries/day)
• Database is subordinate to documents
• Under 3 requests/second average
• Payload sizes stay under 500KB
Move to Postgres when:
• Need atomic writes under concurrency
• Routinely exceed Airtable's 100k monthly calls
• Require real transactions (multi-statement operations)
• Hit Notion's 3 rps or payload limits
Real Client Example: The Three-Tool Solution
Jordan's client who migrated from Notion → Airtable → Supabase ended up using all three:
• Notion: Client-facing project tracker (clients loved the interface, minimal API load)
• Airtable: CRM and pipeline reporting (lightweight relational ops, ~200 updates/day)
• Supabase: Stripe webhook ledger and event processing ($25/month for atomic, idempotent writes)
Running the Numbers
25,000 record changes per day scenario:
Airtable:
• With 10-record batching: 2,500 write calls/day
• 75,000 calls/month (75% of Team plan cap)
• Need Business plan ($45/user/month) when reads push you over
Notion:
• 25,000 API calls/day at 3 requests/second
• Over 2 hours of sustained API time just for writes
• Retry-After he...