SQLite is Eating the Database World (And That's a Good Thing)

Five years ago, if you told a senior backend engineer you were using SQLite in production, they'd laugh you out of the room. SQLite was for prototypes, for mobile apps, for when you didn't have a "real" database yet. Today, SQLite powers Cloudflare D1, Turso, Litestream, LiteFS, and a dozen other serious production infrastructure products. Something fundamental changed.

Let me tell you what changed — and what it means for how you should choose your database in 2026.

The Three Eras of Database Thinking

Era 1: The Monolith Age (Pre-2010)

One database server. Everything connects to it. You scale vertically (bigger machine). Postgres and MySQL dominated because they're battle-hardened, have great tooling, and handle complex workloads.

Era 2: The Microservices Age (2010-2022)

Distributed systems everywhere. Each service gets its own database. NoSQL explodes (MongoDB, Cassandra, DynamoDB). The assumption: you need horizontal scalability at the database layer.

Era 3: The Edge Age (2022-Present)

The server disappears. Code runs at the edge (Cloudflare Workers, Vercel Edge, Fastly Compute). Traditional TCP-based databases can't follow you there. You need an embeddable database — one that runs in your runtime, not beside it.

🧠

Insight

SQLite's killer feature in 2026 is not performance — it's embeddability. It runs in the same process as your code. No network round-trip to the database. No connection pooling. No latency spikes. The database is literally a function call.

The Modern SQLite Stack

TypeScript

// Turso: SQLite distributed globally, with HTTP access
// Drizzle: Type-safe ORM with SQLite dialect

import { drizzle } from "drizzle-orm/libsql";
import { createClient } from "@libsql/client";

const client = createClient({
  url: process.env.TURSO_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN!,
});

const db = drizzle(client);

// This runs from a Cloudflare Worker in Frankfurt.
// The Turso replica is in Frankfurt too.
// Round-trip: ~0.3ms. Compare that to ~45ms to a US-East Postgres.
const users = await db.select().from(usersTable).limit(10);

Turso's architecture is ingenious: you create a "primary" database and then "replicas" that are placed geographically close to your users. Reads hit the nearest replica. Writes are forwarded to the primary and async-replicated. For read-heavy workloads (which is 95% of web apps), you get sub-millisecond database access from anywhere in the world.

When SQLite Wins, When It Loses

Workload	SQLite/Turso	Postgres	MongoDB
Read-heavy web apps	✅ Excellent	✅ Good	⚠️ Overkill
Edge/Serverless functions	✅ Native	❌ TCP only	❌ TCP only
Complex JOIN queries	✅ Excellent	✅ Excellent	❌ No JOINs
High-concurrency writes	⚠️ Limited	✅ Excellent	✅ Good
Full-text search	✅ FTS5 built-in	⚠️ Extension needed	✅ Atlas Search
JSON/unstructured data	✅ JSON functions	✅ JSONB	✅ Native
Geospatial queries	❌ No native	✅ PostGIS	✅ Built-in
Multi-region writes	⚠️ Turso only	❌ Hard	✅ Atlas Global

⚠️

Warning

SQLite's write concurrency is its Achilles' heel. It uses file-level locking for writes — only one write at a time. WAL mode improves this (concurrent reads during writes), but if your app has hundreds of simultaneous writes, Postgres will outperform SQLite significantly.

The Postgres Case: When You Absolutely Need It

Don't abandon Postgres for:

Financial systems — ACID compliance, row-level locking, complex transactions
Multi-tenant SaaS — Row-level security, schema isolation per tenant
Analytics workloads — Window functions, CTEs, complex aggregations
High-write throughput — Queuing systems, event sourcing, real-time feeds

SQL

-- These Postgres features have no equivalent in SQLite
-- Row-Level Security
CREATE POLICY user_isolation ON posts
  USING (user_id = current_user_id());

-- Window functions for analytics
SELECT 
  user_id,
  revenue,
  SUM(revenue) OVER (PARTITION BY user_id ORDER BY month) as running_total
FROM monthly_revenue;

-- Partial indexes
CREATE INDEX idx_active_users ON users (last_login)
  WHERE is_deleted = false;

🔥

Tip

The best 2026 strategy: SQLite/Turso for your read-heavy application data (blogs, products, user profiles), Postgres for your transactional data (payments, orders, inventory). Different tools for different jobs — and that's fine.

MongoDB in 2026: A Niche Player

MongoDB made sense when your data was genuinely schema-less. Today, most teams use it as a document store with an implied schema anyway — and they pay the price in JOIN performance and data integrity. It's still excellent for:

Content management with highly variable schemas
Real-time event logs and activity feeds
Teams already invested in the Atlas ecosystem

But for greenfield projects in 2026? Start with Postgres or SQLite. You can always migrate to MongoDB if your data truly needs it.

The Migration Story

Moving from SQLite to Postgres is straightforward (same SQL dialect for most queries). Moving from MongoDB to anything relational is painful. Start relational and migrate toward flexibility. Don't start flexible and try to migrate toward structure.

🚀

Important

The most expensive database decision you'll make is the one you'll eventually have to undo. SQLite and Postgres both use standard SQL. Your Drizzle/Prisma schema is portable. MongoDB is a different paradigm — choose it deliberately, not by default.

Conclusion

SQLite winning at the edge isn't a trend — it's a structural shift. The constraints of serverless and edge compute make embedded databases the only viable option, and SQLite is the best embedded database that's ever existed. Meanwhile, Postgres continues to be the gold standard for complex relational workloads.

The question in 2026 isn't "which is the best database?" It's "which layer of my stack am I building, and what does that layer actually need?"

More often than you'd think, the answer is SQLite.

Arjun Singh

Technical Architect

Discuss this Topic More Articles →