Why SQLite

When someone hears that a marketing suite in production runs on SQLite, the first reaction is usually suspicion. SQLite has a reputation as a "toy" database — fine for the prototype, fine for the phone app, but not for "real production," where a Postgres cluster on managed infrastructure is supposedly mandatory.

That reputation is out of date, and the suspicion hides an important inversion. LaunchWithAgency does not use SQLite despite wanting to be serious. It uses SQLite because its seriousness is a specific kind: that of a suite whose entire proposition — five products, one database — only stays simple, cheap and reliable if the database is a file. This article is the defense of that choice.

What the stack actually is

LaunchWithAgency runs on six pieces, and the whole list fits in a paragraph. Bun as the JavaScript runtime, serving HTTP. Elysia as the routing framework on top of Bun. SQLite, via the built-in bun:sqlite, as the database. Drizzle as the ORM — declarative schemas, imperative migrations. Better Auth for email-and-password login. Resend for transactional email to go out.

There is no cluster. There is no server build step. There is no separate cache layer, no dedicated message queue, no standalone search service. The application is a process that speaks HTTP and reads a database file. That leanness isn't a lack of ambition — it is the ambition. The stated principle is "software that fits in your head": a system one person can understand in full is a system they can operate, debug and evolve without fear.

SQLite in production, without the folklore

Let's face the folklore head-on. Three popular claims about SQLite, and what is actually true.

"SQLite can't handle production." SQLite is, by several measures, the most-used database on the planet — it runs inside every browser, every phone, countless embedded systems. What it is not designed for is one specific pattern: massive concurrent writes, from many clients at once, against the same database. For concurrent reads, it is excellent. And a marketing suite is an overwhelmingly read-heavy workload: pages served, posts rendered, dashboards queried. The writes — a new subscription, an email log, a flow run — are frequent but not massive. SQLite, with WAL mode on, serves that workload with room to spare.

"You'll have to migrate to Postgres when you grow." That sentence treats scale as if there were only one. The scale that matters for LaunchWithAgency is the marketing operation of an agency or a product team — subscribers in the thousands or tens of thousands, not tens of millions. In that range, the database is never the bottleneck, and migrating to Postgres early is solving a problem you don't have by paying with a problem you now do: operational complexity. Designing for the scale you actually live at isn't shortsightedness — it is honest engineering.

"A single file is fragile." It is the opposite. A single file is the most robust thing there is to operate. The backup is cp. Inspection is opening the file with SQLite's command-line tool and running SQL. Portability is total: the entire database travels as an email attachment. Compare that with backing up, inspecting and migrating a managed Postgres cluster — and it becomes clear which of the two is fragile to operate.

> The question "can SQLite handle production?" is the wrong question. The right one is "which production?" — and for the production of a marketing operation, SQLite doesn't just handle it, it is the most solid choice.

The lean stack is what makes the single database viable

Here is the connection that ties this choice to LaunchWithAgency's entire proposition.

The suite's central promise is radical integration: five products reading and writing the same database, with no glue, no synchronization. That promise is easy to make and hard to keep — unless the database is simple enough that "five products on the same database" doesn't introduce an operational nightmare.

With SQLite, "the same database" is literally the same file. The five products open data/local.db and that's it. There is no database server to configure, no connections to apportion, no pools to size, no schema permissions to coordinate between products. Integrating five products is only trivial because the database is a file. If the suite ran on a Postgres cluster, the hard part wouldn't be writing the products — it would be operating the shared infrastructure that unites them. SQLite makes that hard part disappear.

The same goes for the rest of the stack. With no server build step, the code you read is the code that runs. With Drizzle, the schema is declarative and legible — the very tables we described in the other articles are short JavaScript files. With imperative migrations running on boot, starting the system is starting the system; there is no separate orchestration step. Each piece of the stack was chosen for the same reason: so the entire suite fits in the head of whoever operates it.

Lean is a characteristic, not a stage

There is a common narrative in software according to which "lean" is a phase — the provisional state of a young product, naturally to be replaced by something "robust" once it matures. Robust, in that narrative, is a synonym for complex.

LaunchWithAgency explicitly rejects that narrative. Lean here is not a stage to be outgrown — it is a design commitment to be defended. Bun, Elysia, SQLite, Drizzle, Better Auth, Resend are not temporary scaffolding waiting for a cluster. They are the intended final form, because the intended final form is a system one person understands in full.

That is a product advantage, not just an engineering one. A simple system has fewer places for a bug to hide. A database that is a file has a backup model nobody gets wrong. A stack with no cluster has a predictable infrastructure bill. And an operation that fits in your head is an operation that evolves fast — because nobody is afraid to touch what they understand.

> The choice of SQLite is not where LaunchWithAgency cuts costs. It is where it decides what it wants to be: a suite you comprehend, not one you merely trust.