You don't need a big database. SQLite alone is enough.

Before writing a single feature, most indie hackers make one decision that taxes every day that follows: which database to run. Postgres, because “that’s what real apps use.” A managed cluster, because “what if it takes off.” A migration plan for a scale you don’t have yet, for a product nobody has used yet.

For almost every SaaS idea in its first year, that decision is over-engineering. SQLite already does what you need. It’s just spent two decades being underestimated.

“SQLite is too simple, it can’t handle real traffic”

This one is backwards. SQLite is, by most counts, the most widely deployed database engine in the world. That reputation was built on phones and browsers, but that’s not the whole story: it’s also the storage engine behind a PocketStack backend, answering real API calls for real customers, all day.

The reason it still feels “too simple” for a SaaS backend is a comparison problem. Postgres and MySQL are client-server databases. Your backend sends a query across the network to a separate database process, waits for it to answer, and gets a response back.

A PocketStack backend skips that step. SQLite sits as a file right next to the API process serving your customers, not on a separate machine. A read is a function call your backend makes to its own disk, not a network request to another server.

For a small or mid-size SaaS backend, that setup keeps up with a client-server database handling the same traffic, and it removes an entire service you’d otherwise have to run and pay for. The “SQLite can’t take the load” objection usually isn’t about SQLite itself. It’s a leftover instinct from a time when embedded databases meant something flaky. That time is over.

“Okay, but it can’t handle a lot of writes”

This is the one honest objection, and it gets a real answer instead of a dismissal.

SQLite commits writes to a single file, one at a time. WAL mode lets readers keep reading while a writer commits, but there’s still only one writer per file at any given moment.

Point every customer of a multi-tenant SaaS at one shared SQLite file, and they all queue behind each other’s writes. That setup does break under load. Anyone who tells you otherwise is skipping the caveat.

The fix isn’t to abandon SQLite. It’s to stop sharing one file across your whole customer base.

That’s the architecture PocketStack is built on: one SQLite database per app, not one shared database for every app on the platform. When your app writes, it’s writing to its own file. It never queues behind another customer’s traffic, because it was never in the same file to begin with.

Inside a single app, the math holds up too. A typical SaaS writes a handful of inserts and updates per user action. That’s nowhere near where a single-writer file starts to strain.

To feel that ceiling, you’d need sustained, high-frequency writes from thousands of concurrent users hitting the exact same app. Most products never get there. The ones that do have a good problem, not a launch-day risk.

We didn’t just claim this, we benchmarked it on hardware sized like our production servers. See the numbers: 1,819 requests per second, zero errors.

“I’ll be stuck writing raw SQL, or I’ll outgrow it and have to migrate”

This objection is really two fears wearing one coat: losing the “create an account and start building” experience Supabase made popular, and getting locked into a rewrite later.

Neither holds up. PocketStack runs on PocketBase, which gives you the same category of developer experience: a REST and realtime API generated automatically from your schema, built-in auth, access rules, file storage, and an admin UI to manage data by hand when you need to.

You define collections and fields. You are not hand-writing CREATE TABLE statements or wiring up a query builder for basic CRUD.

The migration fear is the more interesting one, because it usually points the wrong way. On most platforms, “start small, migrate later” means your data is trapped in someone else’s proprietary format until you pay, in engineering time, to get it out.

On PocketStack, every app is a plain SQLite file running plain, open-source PocketBase. There’s nothing proprietary to unwind.

If you ever need more than PocketStack gives you, you already own the file. Download it and run it yourself. No migration project, no data export ticket, no “talk to sales.”

Starting on SQLite doesn’t create a future migration. Starting on a platform that locks your data away does.

Try it on your next idea

None of this means Postgres is wrong. It means Postgres is a decision you make when you actually need it, not a tax you pay on day one out of habit.

PocketStack’s free tier gives you 3 apps, 500 MB each, 100k requests a month, and 5 GB of egress, no credit card required. That’s enough room to prototype a real idea, put it in front of users, and find out if it’s worth the bigger database before you build one.

FAQ

Can SQLite handle production traffic for a SaaS app?

Yes, for the traffic profile of most small to mid-size SaaS products. On PocketStack, SQLite runs as a file right next to the backend process serving your API, so reads are in-process function calls instead of a network round trip to a separate database server. That holds up well for typical SaaS traffic.

Does SQLite handle concurrent writes?

A single SQLite file allows one writer at a time, so sharing one file across every customer of a multi-tenant app will bottleneck. The fix is isolating each app or tenant to its own SQLite file, which is how PocketStack is architected, so one app's writes never queue behind another's.

Will I need to write raw SQL, or migrate off SQLite later?

No. PocketBase, which PocketStack runs on, generates a REST and realtime API, auth, and an admin UI from your schema, so you're not hand-writing SQL for basic CRUD. And because every app is a plain SQLite file with no proprietary lock-in, there's no forced migration if you outgrow the platform: you already own the data.