Next.js + SQLite

Turso and D1 solve the same problem in different places, and a plain file solves it only on a host with a real disk. Turso is the safe default for a Vercel deployment: it is a managed network database built on libSQL, so it replicates to edge locations near your users and works from serverless functions that have no persistent disk of their own. D1 is the pick only when the app runs on Cloudflare Workers, where the database is reached through a Worker binding rather than a connection string; that keeps the app and its data on one platform, but the same code will not reach D1 from a Vercel deployment. A plain SQLite file has no managed layer to learn or pay for, and it is the right answer when the app runs on a VPS or another host with persistent storage. Match the database path to the hosting path first, then choose between the two managed options on price and platform fit.

Writes, not storage. SQLite allows a single write transaction at a time, so a workload that writes on every request (event logging, frequent updates to the same rows) starts queueing behind itself long before the data gets large. Both managed paths soften this at the infrastructure level but keep the same serialized write model, so it's a ceiling to plan around rather than something either one removes. Reads stay cheap and generous on both services; see the pricing section for the exact free-tier limits and where the first paid tier lands. A read-heavy app (a content site, a dashboard over slowly changing data) is nowhere near the write ceiling; a write-heavy one should plan the move to PostgreSQL early.

They share a frontend and take opposite positions on everything behind it. Next.js + PostgreSQL is the fuller stack: a client-server database with an ORM and authentication as fixed core picks, and managed Postgres hosts generally starting somewhere around $6 to $15 a month. This stack is deliberately minimal and treats the database as the open decision, shipping no authentication at all and one lightweight ORM. PostgreSQL's advantage is concurrency and maturity: many simultaneous writers, connection pooling through a driver or a proxy, real access control, full-text search and JSON querying. Its cost is that a database server has to be provisioned, backed up, patched and paid for by someone. Choose this stack for prototypes, side projects, read-heavy sites and single-tenant apps where one edge-replicated database is genuinely enough; move up to the PostgreSQL stack once multiple writers, reporting over live data or team-level access are on the roadmap.

The data exports easily; the queries do not. SQLite is a single file, so getting the rows out is the simple part, whether by copying the file or taking a standard dump. What needs rewriting is the data layer: Drizzle keeps dialects in separate modules, so a schema written against its SQLite core has to be redefined against the PostgreSQL core, with every query and generated migration regenerated for the new dialect. Type behaviour changes too. SQLite has dynamic typing and no native boolean or date types, so columns stored as integers and text may become real booleans and timestamps, and indexes, foreign keys and check constraints all need reviewing in the new schema. In practice this is a scheduled port of the database layer with a freeze or dual-write window, not a connection-string swap, so it is worth budgeting before the schema grows features such as full-text search or JSON column queries, where the two engines diverge most.

Not exactly, and the differences show up in predictable places. Locally you get plain SQLite on your own disk with the operating system's file locking. Turso is libSQL over the network, an SQLite fork with its own extensions and replication model, and D1 is SQLite inside Cloudflare's runtime, reached through a Worker binding instead of a connection string. Two consequences follow. In production every read and write crosses a network hop, so a data layer written as if the database were a local file is the first thing to revisit, and Drizzle Kit has to generate migrations for whichever engine is actually deployed, which is easiest to keep honest by running the managed engine in development too. The second trap is writing to a file path on serverless hosting: there is no persistent disk, so those writes vanish with the invocation, which is why this stack's plain-file option only pairs with a host that has real storage.