Why I chose SQLite for a SaaS backend
Hey IH,
I’m building QuietPulse, a small SaaS for cron job monitoring.
One technical choice that surprises people is that I’m using SQLite in production.
Not just for local dev. Not just for an MVP landing page. For the actual app.
Current stack:
- NestJS backend
- Angular frontend
- Prisma ORM
- SQLite database
A lot of founders default to Postgres immediately because it feels like the “real” choice.
I understand that instinct.
But for my stage, SQLite felt like the more rational decision.
Here’s why.
1. I wanted less infrastructure, not more
I’m a solo founder.
I don’t want to manage extra moving parts before I have strong traction. A separate DB server, tuning, backups, connection pooling, more operational surface area, all of that adds weight.
At this stage, I care more about shipping and learning than maintaining infrastructure I may not need yet.
2. My workload is still pretty simple
QuietPulse is not a social network or analytics warehouse.
The core data model is straightforward:
- users
- monitored jobs
- heartbeat events
- alerts
- billing state
That’s real production data, but it’s not a high-concurrency write monster.
I’m not dealing with huge reporting workloads or complicated cross-system queries from day one.
3. Lower ops overhead matters more than theoretical scale
I think a lot of early founders over-optimize for future scale and under-optimize for current focus.
The usual argument against SQLite is basically:
“What if you grow?”
My view is the opposite:
“What if I add complexity too early and slow myself down before growth even happens?”
Right now, fewer services means:
- fewer things to break
- fewer deployment headaches
- less time debugging infrastructure
- lower cost and lower cognitive load
That tradeoff feels worth it.
4. SQLite gets underestimated
SQLite often gets dismissed as “toy tech,” but I think that’s mostly reputation, not reality.
For a lot of small-to-medium products, especially founder-led SaaS apps, it can be completely sufficient for much longer than people assume.
Not forever, obviously.
But “not forever” is true for almost every technical decision.
5. If it becomes a bottleneck, that’s probably good news
I’m using Prisma, so I’m not handcuffing myself forever.
If SQLite eventually becomes the wrong choice, that likely means the product has reached a stage where the migration is justified.
That’s a much better problem to have than building a heavier stack up front for a scale profile that may never arrive.
Where I would not choose SQLite
I wouldn’t force it into every SaaS.
If I had any of these from day one, I’d probably start with Postgres instead:
- heavy concurrent writes
- a larger engineering team
- complex reporting requirements
- multi-tenant workloads with stronger DB-level isolation needs
- obvious scale that already exists, not just imagined scale
So this is not “SQLite is always better.”
It’s more like:
SQLite is often a very reasonable choice when the product is early, the workload is simple, and the founder wants to keep the system lean.
The broader lesson
The real reason I chose SQLite is that I’m trying to optimize for fit, not status.
A lot of founder tech decisions are shaped by what sounds impressive.
But impressive infrastructure is not the same thing as useful infrastructure.
My current rule is:
Pick the simplest thing that is reliable for your current reality, not your fantasy architecture.
That rule has saved me from a lot of unnecessary complexity already.
Curious how other founders think about this.
Have you used SQLite in production for a SaaS?
If yes, what broke first?
If no, what made you rule it out?
This is a mature tradeoff, optimizing for current constraints instead of imaginary scale.
A lot of founders don’t need bigger infrastructure, they need fewer distractions.