Postgres vs SQLite vs Cloudflare D1 untuk SMB stack

TL;DR

• Postgres (managed: Neon/Supabase) untuk SMB > 1 juta query/bulan. Saya rekomendasi default.
• SQLite + Litestream untuk SMB < 500K query/bulan, self-hosted VPS. Cost: $5/bulan termasuk infra.
• Cloudflare D1 untuk edge-distributed read-heavy. Watch — masih ada gotcha untuk write workload.

Konteks saya

5 project SMB Indonesia, 2024-2026:

• 2 pakai Postgres (Neon free tier → paid $19/bulan saat scale)
• 2 pakai SQLite + Litestream di Hetzner VPS $5/bulan
• 1 pakai D1 untuk read-heavy directory listing

Postgres (managed)

Provider yang saya tes: Neon, Supabase, Cloudflare Hyperdrive + Neon.

Pro:

• Battle-tested. JSON, full-text search, row-level security built-in.
• Ecosystem: tooling lengkap (pg_dump, pgAdmin, monitoring)
• Multi-region read replicas (Neon paid plan)
• Connection pooling solved (PgBouncer, Neon’s built-in)

Con:

• Pricing scale dengan storage + compute. Untuk SMB Indonesia, $19-39/bulan acceptable, tapi tidak gratis.
• Cold start untuk serverless setup: Neon free tier compute scales-to-zero, first query setelah idle = 1-2 detik latency.
• Latency dari Indonesia: provider biasanya Asia-Pacific Singapore, latency 80-120ms.

Bila pakai: production SaaS dengan customer paying. Scaling story jelas.

SQLite + Litestream

Setup: SQLite database file di VPS, Litestream replicate ke S3-compatible storage (Cloudflare R2).

Pro:

• Sangat cepat untuk read: query latency < 1ms (in-process)
• Sederhana: 1 file. Backup = copy file.
• Murah: VPS $5/bulan (Hetzner CX11) + R2 storage ~$0.50/bulan = $5.50/bulan total infra.
• Latency Indonesia: kalau Anda host di Singapore VPS, latency dari Jakarta 30-50ms.

Con:

• Concurrent write terbatas: SQLite serialize write. Untuk SMB < 100 write/detik OK, di atas itu jadi bottleneck.
• Tidak ada built-in read replica: scaling read = ganti pendekatan (atau pindah ke Postgres).
• Operasional: Anda manage VPS, OS patching, OS-level monitoring sendiri.

Bila pakai: MVP, internal tool, B2B SaaS dengan customer 10-200. Read-heavy load.

Cloudflare D1

Setup: serverless SQLite distributed via Cloudflare’s edge network.

Pro:

• Distributed read at edge: query dari Indonesia = read dari Jakarta PoP. Latency 5-15ms.
• Pricing: $5/bulan untuk Workers Paid plan + free 5GB storage, 25 billion row reads/month.
• No server management: serverless, scale otomatis.
• Worker integration: tight integration dengan Cloudflare Workers untuk full edge stack.

Con:

• Write semua route ke primary region: write latency tidak as cepat. Untuk SMB Indonesia dengan write originating dari Indonesia, ini OK (~30-50ms karena Cloudflare smart routing).
• Limit query timeout 30 detik: complex query bisa kena timeout.
• Schema migration: tools-nya developing. Drizzle works, tapi Prisma support limited (Mei 2026).
• Tidak ada full-text search yang sekuat Postgres.

Bila pakai: edge-first SaaS, read-heavy directory/catalog, content site dengan dynamic data.

Benchmark project nyata

Project: SaaS klinik dental BSD, 12 klinik, ~50K queries/bulan.

DB	Query latency p50	Query latency p99	Monthly cost
Postgres (Neon free)	35ms	180ms	$0
Postgres (Neon paid Singapore)	95ms	280ms	$19
SQLite + Litestream (Hetzner Singapore)	0.8ms	12ms	$5.50
Cloudflare D1	8ms	35ms	$5

SQLite menang latency. D1 paling cost-effective. Postgres lambat tapi punya features yang lain tidak punya.

Decision matrix

                           Read traffic
                Low (<100K/mo)    Medium       High (>1M/mo)
              ┌──────────────────┬─────────────┬──────────────┐
Write heavy   │ SQLite+Litestream│ Postgres    │ Postgres     │
(20%+ writes) │                  │             │ (sharded)    │
              ├──────────────────┼─────────────┼──────────────┤
Balanced      │ SQLite+Litestream│ Postgres    │ Postgres     │
              │                  │ or D1       │              │
              ├──────────────────┼─────────────┼──────────────┤
Read heavy    │ SQLite+Litestream│ D1          │ D1           │
              │                  │             │              │
              └──────────────────┴─────────────┴──────────────┘

Migration paths

Common migration story:

1. Start SQLite (MVP, low traffic) → migrate ke Postgres saat write contention atau butuh ekosistem.
2. Start Postgres (default safe) → migrate ke D1 kalau geographic distribution matter.
3. Jangan start D1 kalau Anda tidak sure tentang write pattern Anda.

Migration SQLite → Postgres: butuh sqlite-to-postgres script atau Drizzle’s migration. Take 2-4 jam untuk schema simple, 1-2 hari untuk complex.

Migration Postgres → D1: SQL kompatibel (D1 = SQLite-compatible), tapi feature differences (full-text search, JSON queries). Take 1-2 hari research + execution.

Yang surprising

Klien fotograf billing yang awalnya saya rekomendasi Postgres, ternyata setelah 6 bulan production peak query: 12K query/hari = ~3.6 query/detik. SQLite over-deliver untuk workload ini. Saya migrate ke SQLite + Litestream di bulan ke-7, save $19/bulan, latency turun ~80%.

Pelajaran: jangan default ke “Postgres karena enterprise”. Profile load dulu, pilih sesuai data.

Kapan harus pindah ke yang lebih besar

SQLite → Postgres saat:

• Write contention nyata (lock wait > 100ms regular)
• Butuh full-text search yang sopistikated
• Butuh row-level security multi-tenant
• Storage > 100GB

Postgres → distributed (Citus, CockroachDB) saat:

• Single Postgres tidak cukup (> 50K query/detik sustained)
• Untuk SMB Indonesia, ini sangat jarang. Saya belum pernah encounter di klien saya.

Verdict

Recommended: pilih berdasarkan profile, bukan default ke “yang paling powerful”.

• Default SMB Indonesia 2026: SQLite + Litestream atau Postgres (Neon) — tergantung scale + comfort dengan VPS management.
• D1 worth dipertimbangkan untuk read-heavy edge use case.
• Hindari Postgres “karena enterprise” tanpa workload yang justify cost.