Data Layer Decision Calculator (Airtable vs Notion vs Supabase)

How many records you expect to create or update per day across all automations and integrations. This drives write pressure for Airtable and Notion.

• Default: 5,000
• Valid range: 0–10,000,000

Average records read per second across all automations (e.g., scheduled summaries, list views). If you mostly fetch single records by ID, set [Records Per Read Request] lower.

• Default: 0.5
• Valid range: 0–1,000

Average records written per second (beyond the daily total if you also have continuous streams). Use this with [Burst Factor] to check per‑second ceilings.

• Default: 0.2
• Valid range: 0–1,000

Multiplier for short peaks over your averages (e.g., a cron fan‑out at :00). Peak = Average × Burst Factor.

• Default: 3
• Valid range: 1–20

How many records you can group per request when writing to Airtable. Airtable supports up to 10.

• Default: 10
• Valid range: 1–10

How many records your typical list/read request returns. Airtable and Notion database queries return up to 100 per page.

• Default: 100
• Valid range: 1–100

Approximate payload size for a single Notion page upsert, in kilobytes. Requests over 500 KB must be split.

• Default: 20
• Valid range: 1–500

Total blocks you write per Notion page (text blocks, headings, etc.). Requests over 1,000 blocks must be split.

• Default: 50
• Valid range: 1–1,000

If you update relation or multi‑select properties, how many IDs do you touch per row on average. Notion limits each update to 100 items.

• Default: 0 (if none)
• Valid range: 0–1,000

Simultaneous clients or workers that may hit your database during peaks (webhooks, job runners, AI agents, dashboards). Used to size Supabase pooled/session capacity.

• Default: 50
• Valid range: 1–12,000

Do you need multi‑statement, atomic transactions or long‑running sessions?

• Options: none (simple single‑statement ops), short (<1s transactions OK), long (multi‑statement or ≥2s transactions)
• Default: short

All‑in monthly target for your data layer (tools + hosting). Used to sanity‑check plan picks.

• Default: 50 (USD)
• Valid range: 0–5,000

Compute expected monthly API calls including batching and page sizes.

Formulas (30‑day month):

• Writes/day (Airtable) = ceil([Daily Record Changes] / min([Airtable Batch Size], 10))
• Reads/day (Airtable) = ceil(([Avg Reads per Second] × 86,400) / [Records per Read Request])
• Total calls/month (Airtable) = (Writes/day + Reads/day) × 30

Rate limits and plan checks:

• Peak req/s (Airtable) = ceil(([Avg Writes per Second] × [Burst Factor]) / min([Airtable Batch Size], 10)) + ceil(([Avg Reads per Second] × [Burst Factor]) / [Records per Read Request])
• Airtable per‑base ceiling: 5 req/s
• Team plan monthly cap: 100,000 API calls (Free: 1,000)

Outputs:

• Airtable: Calls/Month
• Airtable: Peak rps vs 5 rps → Pass/Fail
• Airtable: Team 100k Cap → Pass/Fail
• Notes: Business/Enterprise may lift monthly caps, but 5 rps/base remains.

Estimate how many requests each write needs and whether your burst traffic fits ~3 rps average per integration.

Per‑write chunking:

• chunks_blocks = ceil([Notion: Avg Blocks per Page] / 1,000)
• chunks_payload = ceil([Notion: Avg Payload KB per Page] / 500)
• chunks_relation = ceil(max(1, [Notion: Relation Items per Row]) / 100)
• chunks_per_write = max(1, chunks_blocks, chunks_payload, chunks_relation)

Totals (30‑day month):

• Writes/day (Notion) = [Daily Record Changes] × chunks_per_write
• Reads/day (Notion) = ceil(([Avg Reads per Second] × 86,400) / [Records per Read Request])
• Total requests/month (Notion) = (Writes/day + Reads/day) × 30

Burst check:

• Peak rps (Notion) = ceil([Avg Writes per Second] × [Burst Factor]) × chunks_per_write + ceil(([Avg Reads per Second] × [Burst Factor]) / [Records per Read Request])
• Notion guidance: ~3 rps average per integration; handle 429 with Retry‑After.

Outputs:

• Notion: Requests/Month
• Notion: Chunks/Write (how many API calls per row upsert)
• Notion: Peak rps vs ~3 rps → Pass/Flag

Pick connection mode by transaction needs, then ensure pooled/session caps meet your peak clients. Start with the smallest compute that clears your cap and upgrade under load tests.

Connection mode:

• If [Transactions Required] = long → Use Session/Direct (port 5432)
• If short or none → Prefer Transaction Pooler (port 6543) for higher fan‑in

Capacity targets (as of Apr 2026 examples):

• Micro: ~60 direct / ~200 pooled clients
• XL: ~240 direct / ~1,000 pooled clients
• Largest tiers: up to ~500 direct / ~12,000 pooled

Sizing logic:

• Required pooled cap = [Peak Concurrent Clients] (if using transaction pooler)
• Required direct cap = [Peak Concurrent Clients] (if using session/direct)
• Recommended starting size:
  • If pooled and ≤ 200 → Micro
  • If pooled and 201–1,000 → XL
  • If pooled and > 1,000 → choose a compute size with pooled cap ≥ requirement (e.g., multi‑XL)
  • If session/direct and ≤ 60 → Micro; 61–240 → XL; > 240 → larger tier with direct cap ≥ requirement

Outputs:

• Supabase: Mode (6543 pooled vs 5432 session)
• Supabase: Minimum capacity needed (pooled or direct)
• Supabase: Starting compute suggestion

Supabase Pro is per‑org. Compute is billed hourly; Pro includes credits.

Assumptions (Apr 2026):

• Pro plan base: $25/month/org
• Included compute credits: $10/month
• Typical compute prices: Micro ≈ $10/mo, Small ≈ $15/mo, Medium ≈ $60/mo (billed hourly)

Cost math:

• Net compute = max(0, Compute Price − $10 credit)
• Supabase Pro Total = $25 + Net compute

Examples:

• Micro: $25 + max(0, 10 − 10) = $25
• Small: $25 + max(0, 15 − 10) = $30
• Medium: $25 + max(0, 60 − 10) = $75

Output:

• Supabase: Estimated monthly total ($) for your suggested compute size

Deterministic rules that turn your inputs into a clear pick. The calculator evaluates all three and returns the highest‑confidence recommendation plus runners‑up.

Decision rules (evaluated in order):

1. If [Transactions Required] = long → Recommend Supabase.
2. Else if Supabase capacity required (from prior step) exceeds Airtable/Notion ceilings anyway (e.g., [Peak Concurrent Clients] > 200 and you can’t tolerate queueing) → Recommend Supabase.
3. Else compute Airtable fit:
   • Airtable rps check = Peak rps ≤ 5 AND Team 100k cap check = Calls/Month ≤ 100,000.
   • If both pass → Airtable viable with headroom chips (rps headroom, % of monthly cap).
4. Compute Notion fit:
   • Notion rps check = Peak rps ≤ ~3 AND Chunks/Write ≤ 2 (practical ceiling for low‑ops builds).
   • If both pass → Notion viable with headroom chips.
5. If both Airtable and Notion are viable:
   • If your data is primarily documents with light database needs → Prefer Notion.
   • If your data is primarily rows/tables with lightweight relations → Prefer Airtable.
6. If neither is viable → Recommend Supabase.

Outputs:

• Primary Recommendation (Airtable, Notion, or Supabase)
• Why (the binding threshold)
• Secondary Option (if close) with the trade‑off noted

Constants the sheet uses. Update if vendor docs change.

Airtable (Apr 2026):

• Per‑base rate limit: 5 requests/sec
• Batch writes: up to 10 records/request
• List page size: up to 100 records/request
• Monthly API caps: Free 1,000; Team 100,000 (Business/Enterprise: higher/unspecified)

Notion (Apr 2026):

• Average limit: ~3 requests/sec per integration (bursts allowed; respect Retry‑After on 429)
• Payload ceiling: 500 KB per request
• Blocks ceiling: 1,000 blocks per request
• Relation/multi‑select update: 100 items per request
• Database query page size: up to 100 results/request

Supabase (Apr 2026 examples):

• Connection modes: session/direct (5432), transaction pooler (6543)
• Example caps: Micro ~60 direct / ~200 pooled; XL ~240 direct / ~1,000 pooled; largest tiers up to ~500 direct / ~12,000 pooled
• Pro plan: $25/mo/org with $10/mo compute credits; example compute: Micro ≈ $10, Small ≈ $15, Medium ≈ $60