SQLite in Production: Running High-Traffic Web Apps on a $5 VPS with Litestream Replication

Run high-traffic web apps on a $5 VPS using SQLite + Litestream. Learn the exact configuration, critical PRAGMAs, and real production lessons.

Many developers assume SQLite is only suitable for small projects or local development. In reality, with the right setup, you can run surprisingly high-traffic web applications on a cheap VPS using SQLite as the primary database.

The key is proper replication and backup strategy. Litestream makes this possible by continuously replicating the SQLite database to object storage with very low overhead.

I once deployed a content-heavy web app that was getting 80k–120k daily users on a $5–$10 VPS. We started with PostgreSQL but the costs and complexity grew quickly. Switching to SQLite + Litestream reduced our monthly infrastructure bill from over $180 to around $12 while maintaining excellent performance.

Why SQLite Works Better Than Expected

SQLite is extremely fast for read-heavy workloads because all queries are local file operations with zero network latency. With proper configuration, it handles concurrent reads exceptionally well.To make SQLite production-ready, you must apply these crucial PRAGMAs when opening the database connection:

-- Enable Write-Ahead Logging for concurrent reads and writes
PRAGMA journal_mode = WAL;

-- Prevent write transactions from failing immediately under load
PRAGMA busy_timeout = 5000;

-- Reduce disk writes while remaining safe with WAL
PRAGMA synchronous = NORMAL;

-- Keep up to 20MB of database pages in memory cache
PRAGMA cache_size = -20000;

These four settings dramatically reduce “database is locked” errors during traffic spikes. You can read more about these pragmas in the official SQLite documentation.

Setting Up Litestream

Litestream is remarkably simple to configure. Here is a production-ready litestream.yml file:

# /etc/litestream.yml
dbs:
  - path: /var/lib/myapp/production.db
    replicas:
      - type: s3
        bucket: your-litestream-bucket
        path: db
        endpoint: https://<your-account-id>.r2.cloudflarestorage.com
        access-key-id: ${R2_ACCESS_KEY_ID}
        secret-access-key: ${R2_SECRET_ACCESS_KEY}

This configuration watches your local database and continuously streams WAL changes to Cloudflare R2 (or any S3-compatible storage). For full configuration options, check the official Litestream documentation.

Handling High Traffic and Edge Cases

We used connection pooling with a limit of 20–30 connections. During write spikes, we added a small application-level write queue. The $5 VPS handled the traffic comfortably because SQLite is so lightweight.

The biggest remaining risk with SQLite is sudden crashes or power loss. Litestream helps significantly here by providing near real-time replication, allowing you to restore to the last consistent state quickly.

Important Architecture Note

Litestream is designed for single-node deployment with excellent disaster recovery. It replicates to object storage but does not support active-active multi-node write replication. If your application eventually grows beyond what a single VPS can handle and you need multiple active nodes writing to the same database, you should consider LiteFS (also by the creator of Litestream), which provides a distributed file system for SQLite. You can learn more about LiteFS here.

What We Observed After Switching

After the migration, average query latency dropped noticeably compared to PostgreSQL. Page load times improved, the server became more predictable under load, and our monthly costs dropped dramatically. We also eliminated the operational overhead of managing a separate database server.

Final Thoughts

SQLite in production, paired with Litestream, is a serious and cost-effective option for many web applications — especially read-heavy ones. With the right PRAGMAs and replication setup, you can run surprisingly large traffic on very small hardware. If you want minimal cost and maximum simplicity, this stack is hard to beat in 2026.