We've twisted the word serverless into something vague. These days, serverless usually just means "I don't manage the infrastructure, someone else does." Which is fine. But it's also not the full picture.
Because if we take the word literally (no server process to run, configure, or scale) then one database has quietly been the most serverless of all for over 20 years: SQLite.
It doesn't run in the cloud. It doesn't need to connect to a remote API. It doesn't even require a boot-up process.
It just works. And it's criminally underrated.
What Does Serverless Even Mean?
Let's break this down into two flavors:
The Neo-Serverless Model
This is the popular kind. You write your application and connect to a database that is fully managed by a third party. You don't worry about patching, scaling, or provisioning.
Some examples:
- Firebase
- DynamoDB
- Neon
- PlanetScale
- Supabase
- Cloudflare D1
All of these abstract away the server side. You write queries and trust that somewhere behind the scenes, someone else is keeping the lights on.
It's convenient. But make no mistake: servers are still involved.
The Classic Serverless Model
Now consider the opposite. Instead of managing a server, or outsourcing one, what if you never needed one in the first place?
This is where SQLite fits in.
SQLite isn't a service. It's a library. It runs entirely inside your application process. There's no separate daemon. No TCP connection. No sockets. You just open a file and start reading and writing data.
No provisioning. No pricing calculator. No logs dashboard. Just data, right there next to your code.
SQLite's Serverless Nature Still Matters
Most apps today are built on top of unnecessary infrastructure. Postgres servers. load balancers. cron containers. This complexity is often introduced before anyone asks if it's even needed.
The truth is, a lot of software could be built entirely on SQLite. If you actually step back and look at your app's behavior honestly, you'll find that many products are primarily read-heavy. They're not constantly writing thousands of updates per second. They're serving content, reading data, and occasionally writing some changes.
For that kind of workload, SQLite is not just acceptable. It's ideal.
You get a single file as your database. You don't have to spin up a server for local development. You can start building instantly: just run your app and point it to a file.
No need to:
- Create users or roles
- Set up SSL
- Manage connection pools
- Provision read replicas
- Configure backup jobs
In development, that's huge. You can clone a repo, run the app, and it just works. No database service to connect to. No dependencies to install. No setup required.
And in production, copying your entire database is as simple as uploading one file to S3. No complicated backup pipeline. No risk of logical corruption across multiple hosts. Just sync the file and you're done.
When to Use SQLite (Yes, Even for SaaS)
Let's talk seriously about modern SaaS.
Most SaaS tools have a very familiar structure:
- CRUD dashboards
- Read-heavy user interfaces
- Occasional writes, often from authenticated users only
- Analytics or reporting dashboards
- Admin panels with moderate usage
None of these require a massive transactional engine. Unless you're building Stripe or Notion or something like that, your write volume is probably minimal. Even if it feels like there's a lot going on, you're rarely hitting thousands of writes per second.
And for moderate write throughput, SQLite can easily keep up, especially with WAL (Write-Ahead Logging) enabled. WAL dramatically improves write performance by letting writes happen in parallel with reads, making SQLite more than fast enough for many production apps.
You also get:
- Instant setup: no dev or staging environment issues
- Simple backups: copy a file to S3 and you're done
- Easy scaling for many use cases: read replicas with Litestream, or shipping daily exports to analytics platforms
SQLite works especially well for:
- Internal tools and dashboards
- Local-first applications with sync layers
- Edge-deployed apps (Cloudflare, Fly.io, Deno Deploy)
- Browser extensions
- Small-to-mid SaaS products with moderate concurrency needs
Even if you plan to move to Postgres later, SQLite can be your default starting point. You'll save weeks of infrastructure setup and focus on building the product.
Final Thoughts
We've somehow convinced ourselves that every new app needs a full-stack of cloud services just to show a dashboard. It doesn't. Most of the time, you just need to write and read some data, and SQLite does that with zero setup, zero friction, and zero infrastructure.
It's the original serverless database. Still quietly powering millions of apps. Still better than half the stuff we over-engineer today.
If you're building something and want an easy way to collect user feedback, track suggestions, and publish updates, try UserJot. It gives you a feedback board, roadmap, and changelog in one place: no backend to set up. Just drop it in and ship.
Top comments (1)