The One-File Backend: Scaling a SaaS on SQLite & PocketBase

Introduction: The Cult of Complexity

We have been gaslit by the cloud industry.

For the last fifteen years, a narrative has been carefully constructed by cloud providers and enterprise software vendors. It goes like this: “If you want to build a serious application, you need a serious architecture.”

A “serious architecture,” according to this narrative, involves a Virtual Private Cloud (VPC), a managed Postgres instance (RDS), a Redis cluster for caching, an ElasticSearch cluster for search, a fleet of stateless Docker containers orchestrated by Kubernetes, and a complex CI/CD pipeline to glue it all together.

If you are Netflix, serving 200 million concurrent streams, this is valid engineering.

If you are a Zero-Headcount Enterprise—a solo founder or a small team building a SaaS on a 16GB laptop—this is not engineering. It is financial and cognitive suicide.

We have adopted the tools of the giants to solve the problems of the mice. We pay a “Complexity Tax” every single day. We pay it in monthly AWS bills, we pay it in the RAM required to run Docker Desktop, and most importantly, we pay it in the mental bandwidth required to maintain a distributed system when all we really wanted was a place to store users and todos.

PocketBase.

Under the hood, it runs on SQLite. And contrary to everything you have been told, it is not a toy. It is the most efficient, performant, and logical way to build a SaaS in 2026. Here is why the future of the Zero-Headcount Enterprise is a single file.

Part 1: The “Network Call” Fallacy

To understand why SQLite is superior for the vast majority of applications, we have to talk about physics. Specifically, the physics of latency.

In a standard Postgres setup, your application code (running in Node.js, Python, or Go) lives in one process. Your database lives in another process. Often, they live on different servers entirely.

Every time you want to fetch a user, your application has to:

1. Open a TCP connection (or borrow one from a pool).
2. Serialize the SQL query.
3. Send the query over the network wire.
4. Wait for Postgres to parse, plan, and execute.
5. Wait for the data to come back over the wire.
6. Deserialize the data.

This is the Client-Server Database Model. It creates a fundamental separation between your logic and your data. The speed of light and the overhead of the TCP/IP stack become your bottleneck.

SQLite is different.

SQLite is not a server. It is a library. It is code that links directly into your application. When you query SQLite, there is no network call. There is no serialization. There is no TCP handshake.

Your application simply makes a function call to the hard drive.

The Speed of “In-Process”

On a modern NVMe SSD (like the one in my 16GB laptop), SQLite is shockingly fast. We are talking about microsecond latency, not millisecond.

When your data lives inside your application process, the concept of the “N+1 Problem” (the deadly sin of SQL performance where you make too many queries) almost disappears. You can run 1,000 queries in a loop against SQLite in less time than it takes to open a single connection to a remote Postgres server.

By switching to SQLite, you aren’t just changing databases; you are removing the Network Barrier. You are collapsing the stack. You are turning a distributed system into a monolithic one.

And in the world of the Zero-Headcount Enterprise, the Monolith is King.

Part 2: PocketBase – The Missing Link

For years, the argument against SQLite was: “Okay, it’s fast, but I need a backend. I need Authentication. I need an API. I need an Admin Dashboard. I don’t want to build that from scratch.”

Enter PocketBase.

PocketBase is an open-source backend written in Go. It uses SQLite as its storage engine. But it is not just a database wrapper; it is a Vertical Integrated Platform.

In a single binary file (about 30MB), PocketBase gives you:

1. Realtime Database: Subscriptions to data changes (like Firebase).
2. Authentication: Email/Password, OAuth2 (Google, GitHub, Apple) fully implemented.
3. File Storage: Handles uploads to local disk or S3 automatically.
4. Admin UI: A beautiful, responsive dashboard to manage your data.
5. API: Auto-generated REST APIs for every collection you create.
6. SDKs: Type-safe clients for JavaScript and Dart.

The Validation

If you try to run the equivalent stack using standard tools, you would need:

• A Docker container for Postgres (500MB RAM).
• A Docker container for Redis (100MB RAM).
• A Docker container for MinIO/Storage (200MB RAM).
• A Node.js process for your API (150MB RAM).
• A React App for your Admin Dashboard (Build step + Hosting).

PocketBase does all of this using ~20MB of RAM when idle.

On my 16GB laptop, I can run twenty different PocketBase instances for twenty different freelance clients, and my fans don’t even spin up. It is the ultimate efficiency flex. It respects your hardware.

Part 3: The Myth of “Scale”

The moment you mention SQLite in a developer forum, a Senior Architect will inevitably push up their glasses and ask: “But does it scale?”

This is the most damaging myth in our industry. It is driven by Resume Driven Development—engineers choosing tools that look good on a CV rather than tools that fit the problem.

Let’s look at the reality of “Scale” for a Zero-Headcount SaaS.

The Vertical Scaling Reality

Modern hardware is absurdly powerful. A standard $60/month dedicated server (e.g., from Hetzner) gives you 64GB of RAM and a 16-core CPU.

SQLite, running in WAL (Write-Ahead Log) Mode, can handle tens of thousands of concurrent reads and thousands of concurrent writes per second on this hardware.

Unless you are building the next Twitter or Uber, you will likely never outgrow a single server with SQLite.

• Are you processing 100,000 requests per second? No.
• Do you have 10 Terabytes of relational data? No.
• Do you need active-active multi-region writes? No.

You have 5,000 users. You have 500 active daily sessions. SQLite effectively laughs at this load. It considers this “idle.”

We optimize for a scale we will literally never reach, and in doing so, we cripple our velocity today. The Zero-Headcount founder understands that if they ever do reach the limits of SQLite, they will be making so much money that they can hire a team of ten engineers to migrate to Postgres then.

Premature optimization is the root of all evil. Premature scaling is the root of all bankruptcy.

Part 4: The Deployment Dream (The Copy/Paste Deploy)

The most underrated aspect of the “One-File Backend” is the deployment experience.

In the Docker/Kubernetes world, deployment is a nightmare pipeline of YAML files, container registries, build steps, and health checks.

In the PocketBase world, deployment is: Copying a file.

Because PocketBase is a compiled Go binary, it has no dependencies. It doesn’t need Node.js installed on the server. It doesn’t need Python. It doesn’t need shared libraries.

The Workflow

1. Local Dev: I run ./pocketbase serve on my laptop. I build my app.
2. Deploy: I scp (secure copy) the binary to my VPS.
3. Restart: I restart the system service. Time taken: 200ms.

Because the database is also just a file (pb_data.db), migration is equally simple. I can pull the production database to my local machine to debug an issue by simply downloading the file.

Data Safety & Backups (Litestream)

“But what if the server disk dies?”

This is the only valid concern with a local file database. And it is solved by a tool called Litestream.

Litestream is a sidecar process that hooks into SQLite’s WAL mode. It replicates every single write to an S3 bucket (like AWS S3 or Cloudflare R2) in near real-time.

It effectively gives you Point-in-Time Recovery for pennies.

• Disaster Scenario: Your server catches fire and dissolves.
• Recovery: You spin up a new server. You install Litestream. You run litestream restore. It pulls the data from S3. You are back online in 5 minutes with zero data loss.

You have achieved the reliability of a managed RDS instance without the $400/month bill and without the complex VPC networking.

Part 5: The Developer Experience (DX)

The final argument for the One-File Backend is the sheer joy of using it.

When you remove the layers of abstraction, you regain a sense of control over your software.

• No “Connection Refused”: The database is a file. If the disk is there, the database is there.
• No “Version Mismatch”: The backend and the database engine are compiled together.
• No “OOM Kills”: You aren’t running a Java VM or a heavy container orchestration layer.

On my 16GB laptop, this stack flies. I can run my frontend (Next.js or HTMX), my backend (PocketBase), and my AI agents all simultaneously. The constraint of the hardware is respected.

The Mental Shift

The shift here is from “Managing Services” to “Managing State.”

When you use Postgres, you are managing a service. You have to care about its uptime, its configuration, its version.

When you use SQLite, you are managing a file. It is a passive asset. It works for you; you don’t work for it.

For the Zero-Headcount founder, this mental freedom is priceless. Every hour you don’t spend debugging a Docker network bridge is an hour you spend talking to customers or improving your product.

Conclusion: Simplicity is the Ultimate Leverage

The software industry is cyclic. We went from Mainframes to PCs, from Monoliths to Microservices. Now, the pendulum is swinging back.

We are entering the era of the Modular Monolith and the Local-First Database.

The “One-File Backend” is not a regression; it is an evolution. It acknowledges that hardware has outpaced software complexity. It acknowledges that for 99% of businesses, the bottleneck is not the database’s ability to handle writes—it is the developer’s ability to ship features.

If you are a solo founder, an indie hacker, or a lead engineer at a lean startup, I implore you to audit your stack.

Look at your Docker Compose file. Look at your AWS bill. Look at your CI/CD logs.

Ask yourself: How much of this is actually delivering value to my user, and how much of this is just me roleplaying as a Google Site Reliability Engineer?

You don’t need Kubernetes. You don’t need Microservices. You don’t need RDS.

You need a fast VPS, a single Go binary, and a file called data.db.

Reclaim your time. Reclaim your RAM. Scale your ambition, not your infrastructure.

Key Takeaways for the Engineer:

1. Latency Matters: SQLite runs in-process. It is physically faster than any networked database can ever be.
2. PocketBase is the Key: It turns raw SQLite into a shipping-ready SaaS platform with Auth and APIs.
3. Vertical Scaling Wins: A single server with SQLite can handle millions of requests a day. Don’t optimize for problems you don’t have.
4. Backups are Easy: Litestream makes SQLite as durable as any enterprise cloud database.
5. Cost: You can run a million-dollar business on $5/month of infrastructure. This is the ultimate competitive advantage.

🚀 Let's Build Something Amazing Together

Hi, I'm Abdul Rehman Khan, founder of Dev Tech Insights & Dark Tech Insights. I specialize in turning ideas into fast, scalable, and modern web solutions. From startups to enterprises, I've helped teams launch products that grow.

• ⚡ Frontend Development (HTML, CSS, JavaScript)
• 📱 MVP Development (from idea to launch)
• 📱 Mobile & Web Apps (React, Next.js, Node.js)
• 📊 Streamlit Dashboards & AI Tools
• 🔍 SEO & Web Performance Optimization
• 🛠️ Custom WordPress & Plugin Development

💼 Work With Me