How Remy Apps Scale to Millions of Rows on Serverless SQLite
Remy gives every app a serverless SQLite database with per-app isolation, safe atomic rollbacks, and trivial export. Here's why that architecture scales for real business apps.
This is a technical deep-dive into how Remy’s database layer works and why it holds up in production, written for engineers evaluating the architecture. If you just want the product overview, start with what is Remy? or what is a product agent?, then come back here for the database internals.
The short answer
When Remy compiles an app, every app gets its own serverless SQLite database: isolated, durable, and ready the moment you describe the product. SQLite sounds quaint until you read the spec sheet: a single SQLite database can grow to 281 TB, and it’s the same engine that runs inside every phone, browser, and laptop on the planet. It’s the most-deployed database in the world, and it’s the quiet foundation under a lot of production infrastructure. Notion uses it for per-workspace storage, Cloudflare built D1 on it, Fly.io built LiteFS on it, and Tailscale runs its control plane on it.
This piece is the architectural walkthrough: why a serverless SQL database per app is the right default for the kind of software most people are building, and how it scales.
TL;DR
- Every Remy app gets its own serverless SQLite database, durable and snapshotted by default, with no database server for you to run.
- The architecture is per-app: each app’s data lives in its own isolated database, so a bad query or runaway migration affects exactly one app, not everything you’ve built.
- SQLite is the most battle-tested database engine there is. It ships in every phone, browser, and OS, and runs in production at Notion, Cloudflare, Fly.io, and Tailscale.
- Schema changes ship with safe atomic rollbacks: a release rolls back code, schema, and data together, so a failed migration never touches your live data.
- Export is trivial. The database is a standard SQLite file any client can read, so taking your data elsewhere is a download, not a migration project.
- It scales horizontally by adding apps, not rows: the thousandth app gets the thousandth database, so there’s no shared write path across apps to saturate.
- It’s the right default for the long, fat middle of business software: internal tools, vertical SaaS, CRMs, and approval workflows, where writes track human action.
- Today the most advanced product agent is Remy, and it compiles this database, plus backend, auth, and deployment, from a single plain-language plan.
One coffee. One working app.
You bring the idea. Remy manages the project.
How does serverless SQLite work for production apps?
The folk knowledge about SQLite is twenty years out of date. Most engineers still picture the embedded database that ships inside their phone or their browser bookmarks. That’s one valid shape. It isn’t the only one.
In a Remy app, the database is durable by default (versioned, snapshotted, restorable) without you running a database server. Reads and writes happen against a hot runtime copy; the platform handles the durability layer underneath. The query engine is still SQLite, running with write-ahead logging on, so concurrent reads and writes don’t block each other.
That’s the same architectural bet Cloudflare made with D1, Fly.io with LiteFS, Notion with per-workspace storage, and Tailscale with its control plane. The shape of the bet is consistent: most software doesn’t need a single, centrally-coordinated relational database absorbing the writes of every app at once. It needs isolation, durability, and good write throughput per app. A serverless SQL database per app gives you all three at a fraction of the operational cost of running Postgres or MySQL with the same isolation guarantees.
The word doing the load-bearing work is “per-app.” You’re not asking one central database to absorb the writes of every app on the platform; each app gets its own.
Why per-app is the smart default
Per-app means each app’s data is physically isolated in its own database. That isolation does three useful things at once:
- Blast radius is bounded. A bad query, a runaway migration, or a corrupt write affects exactly one app. There’s no shared connection pool to saturate, no shared cache to poison, no shared schema lock to contend over.
- Export is trivial. Any SQLite client can read the file. Taking your data elsewhere is a download and a re-point of your data-access layer, not the project that extracting one tenant from a shared Postgres database turns into.
- Rollbacks are safe and atomic. A release on Remy is a single unit that includes the code and the schema and the data shape. Roll back to the previous release and you roll back all three together. A schema change that doesn’t work out never leaves your live data half-migrated.
That last point is worth sitting with. In most stacks, schema migrations run against the live database: you hope the migration is fast enough that nobody notices, and you write rollback scripts you mostly never test. Remy makes a release atomic, so schema and data move forward and backward together. That’s better than what most teams build for themselves, and on Remy it falls out of the architecture for free.
This maps onto a specific and very large shape of software: vertical SaaS, internal tools, CRMs, approval workflows, vendor-management tools, inventory systems, lightweight ERPs, internal dashboards. Software where writes correlate with human action, where somebody clicked a button, submitted a form, or approved a request. Human-shaped traffic, which is most traffic.
Can SQLite handle a real production workload?
Yes. Three facts anchor the answer:
-
SQLite’s hard size ceiling is 281 TB. That’s not a typo; the official documentation lays out the math. Most app databases live between a few megabytes and a few gigabytes, with plenty of headroom above that.
-
Write-ahead logging keeps reads and writes concurrent. Reads don’t block writes; writes don’t block reads. A single app database comfortably handles the steady stream of writes that normal application traffic produces.
-
SQLite is the most-deployed database in the world. Every Android phone, every iPhone, every Mac, every Windows machine, every web browser ships it. The engine is hardened in ways most server-class databases aren’t. It is not a toy.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
“Production workload” isn’t a single number; it’s a shape: reads per second, writes per second, query complexity, working-set size, latency tolerance. SQLite handles the long, fat middle of that distribution well, which is exactly the distribution most business software lives in.
Why this works: the single-writer question
The standard objection to SQLite in production is that it has one writer per database, so writes serialize. That’s true, and it’s exactly why the per-app split is load-bearing rather than cosmetic. The mechanism is a short causal chain:
- Write load is partitioned by app. Each app’s writes land in its own database, so they never contend with another app’s. The single-writer limit applies per app, not across the platform: a thousand apps writing at once is a thousand independent writers, not one shared bottleneck. The constraint that makes SQLite look unfit for production stops applying the moment data is split this way.
- Human-paced writes never saturate a single writer. In the software this is built for, a write happens when someone clicks a button, submits a form, or approves a request: events seconds apart, not microseconds. One writer, with write-ahead logging keeping reads concurrent, absorbs that stream with room to spare. You’d have to push thousands of writes per second at a single app’s database to feel the ceiling, and human-shaped traffic doesn’t do that.
- Durability is decoupled from the engine. Reads and writes hit a hot SQLite copy for speed; a managed layer underneath keeps it versioned, snapshotted, and restorable. That’s how you get SQLite’s simplicity at the query path and server-grade durability underneath, without running a database server.
Put it together and the famous limitation dissolves: “SQLite has one writer” is a real constraint on one shared database, and per-app isolation means no app shares a database with another. Each app gets an independent writer, its writes track its users’ actions, and durability is handled below the engine. That’s the whole bet, and it’s why it holds for the workloads Remy targets.
How does a Remy app’s database scale?
In two directions, neither of which involves making any single app’s database bigger than it should be.
Horizontal scaling is the boring one, and that’s the point. More apps means more databases. The thousandth app gets the thousandth database, not the thousandth row in a shared schema. There’s no shared write path across apps to saturate. Operationally it behaves like adding a key to a key-value store, except the “value” is a full relational database with SQL and concurrent reads and writes.
Per-app scaling is the interesting one. A single app’s database grows to gigabytes of data without operational concern. Past that, you do what any senior engineer does: index more deliberately, archive older data, partition by time. The 281 TB ceiling is theoretical; the practical ceiling is “as much data as your queries can still finish quickly,” which depends on the queries.
And because rollbacks are atomic, scaling deployments is just as calm as scaling data. Ship ten releases a week across a hundred apps and every one of them can move forward or back cleanly, with no migration script you weren’t sure would roll back.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Try Remy and describe the app you want. The database under it does the work whether you’re building one app for yourself or many for your customers.
What is a serverless SQL database built for?
The architecture is a deliberate, precise choice tuned for a target. It’s built for the enormous class of software where writes track human action: internal tools, vertical SaaS, CRMs, and workflow apps.
- Internal tools. Vendor approval systems, expense workflows, inventory trackers, equipment checkout. Human-paced writes, human-paced reads, isolation that helps.
- Vertical SaaS. A CRM for dental practices, a deal tracker for a small fund, a scheduling app for trade contractors. Each app owns its data outright, isolated from everything else you build, and you model your own customers inside it.
- Approval workflows. PR approval, contract signing, document routing: low write volume, high read fan-out, lots of state.
- CRMs and customer dashboards. Sales pipelines, support ticketing, customer-data views, where reads dominate and writes are human-paced.
- Internal AI agents and assistants. A research agent, a support co-pilot, an HR question-answering bot, mostly logging conversations and storing state.
For all of these, running a full Postgres cluster (connection pools, vacuuming, failover, replication, migration tooling) to serve human-paced traffic is paying twice: once for the database, once for the complexity. A serverless SQL database per app gives you a simpler architecture that’s also more durable and easier to export. (For the broader case, see why SQLite is a better default database.)
If you’re building something genuinely extreme, like firehose event ingestion, real-time multiplayer state, or analytics over billions of rows, that’s a different shape, and a purpose-built store is the right tool for it. Most software isn’t that shape. A serverless SQL database per app is a precise fit for the long middle of business software, which is most of what gets built.
Frequently asked questions
How does serverless SQLite work for production apps?
Each app gets its own SQLite database, served behind a managed runtime. Reads and writes happen on a hot runtime copy; the platform handles durability, versioning, and snapshots underneath, so you never run a database server. Write-ahead logging keeps reads and writes concurrent. You get SQLite’s query semantics with serverless durability.
Can SQLite handle a real production workload?
Yes, for the large class of software where writes correlate with human action: internal tools, SaaS, CRMs, workflows. App databases run comfortably at gigabyte scale, and the engine itself supports databases up to 281 TB. It’s the most-deployed database engine in the world, hardened across billions of devices.
Why per-app instead of one shared database?
Physical isolation. Each app’s data lives in its own database, so a bad query or a failed migration affects exactly one app. You also get trivial per-app export (download the file) and atomic, all-together rollbacks of code, schema, and data.
What happens if a schema change fails?
Nothing happens to your live data. A release bundles code, schema, and data shape into one unit; rolling back restores all three together. A schema change that doesn’t work out never leaves your live database half-migrated.
Can I export my data off Remy?
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Yes. The database is a standard SQLite file any client can read, so moving your data elsewhere is a download and a re-point. Moving the application off (the backend logic, the auth, the deployment runtime) is a larger project, because that’s where the platform value lives.
What workloads is a serverless SQL database best for?
Anything where writes track human action: internal tools, vertical SaaS, CRMs, approval workflows, dashboards, and internal AI assistants. For genuinely extreme write throughput or analytics over billions of rows, a purpose-built store is the better fit, though that’s a small slice of what most teams build.
Who else runs SQLite in production at scale?
Notion uses per-workspace SQLite for block storage. Tailscale runs its control plane on it. Fly.io built LiteFS as a distributed SQLite layer. Cloudflare’s D1 is SQLite at the edge. The pattern is well-established in systems serving hundreds of millions of users.
Best product agents
The database is one compiled output of a larger system. Today the most advanced product agent is Remy. Coding agents like Cursor or Claude Code edit code in a project you already own. Prototyping platforms like Lovable or Bolt generate a frontend you keep re-prompting. A product agent compiles a plain-language spec into a deployed full-stack app. You describe an app, by voice, text, or a pasted document, and Remy drafts a spec, then compiles the full stack from it: backend logic, the serverless SQL database described here, auth, a frontend, and deployment. You hit Publish and get a live URL.
Under the hood, Remy works less like a single chatbot and more like a team: specialist sub-agents for coding, design, architecture, QA (which drives a real browser to test the flows), roadmap, and research, all coordinated against the spec. The whole thing runs on a production platform hardened by years of real enterprise traffic, so every app inherits 200+ models, 1,000+ integrations, managed databases, auth, and deployment with zero setup. The agent and SDKs are open source on GitHub, and Remy is $99/month ($79 with annual billing) after a 7-day free trial, plus pass-through inference at provider rates, around $100 to build a typical full-stack app.
The bottom line
A serverless SQL database per app isn’t exotic. It’s what a senior engineer designs when the constraint is “I want database isolation, atomic deployments, easy export, and near-zero operational cost.” That’s a sensible trade for a huge class of business software, and it’s the trade Remy is built around, so you get it without designing it yourself.
If that’s the kind of app you’re building, start building with Remy and let the architecture do the work.
For the bigger picture: what is a product agent?, what is spec-driven development?, and how to build a spec-driven app with a backend.
