SQLiteEdge Archive: 8 Production SQLite WAL, PocketBase & Litestream Stack Blueprints

All SQLiteEdge Stack Reference Guides

• BP-01 · SQLite WAL Production PRAGMAs: Zero SQLITE_BUSY at 20,000+ RPS

  Out of the box, SQLite ships with rollback-journal DELETE mode, synchronous=FULL, 2 MiB cache, and a 0ms busy_timeout—designed for embedded phones in 2005, not NVMe servers. Switching to Write-Ahead Logging (WAL), bounding WAL file growth, enabling zero-copy mmap_size, and separating reader/writer connection pools turns a single NVMe VPS into a sub-millisecond OLTP powerhouse.

• BP-02 · PocketBase for 100,000+ Active Users on a $10.49 AMD EPYC NVMe VPS

  PocketBase compiles Go HTTP routing, Realtime Server-Sent Events (SSE), JWT auth, S3 media hooks, and dual-pool modernc/sqlite into one ~38 MB static executable. Because database queries execute in-process with zero TCP serialization overhead, a 4 vCPU / 16 GB Hostinger KVM4 NVMe VPS comfortably serves 100,000+ monthly active users and 15,000+ open SSE streams.

• BP-03 · Litestream Continuous S3 Replication Without Surprise AWS PUT API Bills

  A single-node SQLite VPS without continuous off-site streaming is a single point of hardware failure; paired with Litestream, it achieves ~1-second Recovery Point Objective (RPO) rivaling managed multi-AZ RDS. However, syncing every 1 second triggers 2.59 million S3 PUT checks/uploads per billing cycle per database—making fixed-price self-hosted MinIO/Garage on a $6/mo InterServer 1TB slice dramatically cheaper than metered AWS S3.

• BP-04 · Rails 8 + SolidQueue, SolidCache & SolidCable on Kamal 2 NVMe VPS

  Rails 8 made SQLite a first-class production citizen by shipping SolidQueue, SolidCache, and SolidCable alongside automatic WAL/IMMEDIATE patches in ActiveRecord. The golden rule on a Kamal 2 single-server deployment is four separate SQLite files (`production.sqlite3`, `queue.sqlite3`, `cache.sqlite3`, `cable.sqlite3`) so high-churn cache evictions and job polling never contend with customer checkout writes.

• BP-05 · Bun:sqlite & Node.js better-sqlite3: Why Synchronous Beats Async Pools at 25k RPS

  JavaScript developers instinctively reach for async database drivers, yet async wrappers around SQLite (like node-sqlite3) serialize mutex queues across libuv threads and tank throughput. Both `better-sqlite3` on Node.js and native `bun:sqlite` execute synchronously inside the thread in ~8–25 microseconds, eliminating N+1 latency and hitting 25,000+ HTTP RPS when paired with micro-batched write queues.

• BP-06 · Self-Hosted LibSQL (sqld): Turso HTTP/Hrana & Embedded Replicas Without Row Fees

  LibSQL (`sqld`) extends SQLite with an HTTP/WebSocket Hrana wire protocol, native `F32_BLOB` DiskANN vector indexes, virtual WAL hooks, and local embedded replicas—powering serverless functions that cannot mount a persistent disk. Self-hosting `sqld` on a Vultr High-Frequency NVMe primary gives you the exact `@libsql/client` SDK ergonomics with zero per-billion row-read or per-million row-write overage fees.

• BP-07 · Local PCIe NVMe vs AWS EBS gp3: Why Network fsync Kills SQLite Throughput

  Most "SQLite cannot scale writes" myths originate from engineers benchmarking SQLite on AWS EC2 backed by network-attached EBS gp3 or DigitalOcean Block Volumes. Because SQLite serializes writes through one lock at a time, throughput is strictly `1 / lock_hold_time`. Adding a 1.15ms network storage round-trip to every WAL sync or checkpoint drops ceiling throughput from ~22,000 TPS down to ~1,350 TPS.

• BP-08 · Multi-Tenant Database-Per-User SQLite: Unlimited Horizontal Write Scaling on One VPS

  SQLite's "single writer" lock applies per file—not per server! When your B2B SaaS assigns each organization (`tenant_8492.sqlite3`) its own file on a 12-core NVMe VPS, 12 different tenants write simultaneously across all 12 CPU cores with zero lock contention, cryptographic-grade tenant isolation, zero row-level-security bugs, and instant 1-file customer data exports.