Sometimes the best option is the simplest, even when it comes to databases. While many developers reach for Postgres or MySQL by default, might it be better to take the more lightweight approach to get something shipped?

That’s where SQLite comes in handy – a serverless, single-file database that can sit amongst your project files. With no server to run, no connections to manage, and no infrastructure to maintain, it makes getting started simpler faster, and cheaper. Sounds great for a prototype, but how reliable is this in production?

I ran a niche community social bookmarking site (around 100-200k pageviews per month) on SQLite for several years and it was no problem at all. (source: HackerNews)

It turns out, it can be pretty good – there's everything from Kanban apps and Airtable clones, to job boards and video streaming services out there in the wild, running in production solely on SQLite databases.

In this post, I'm showing a bunch of examples to demonstrate what's possible with less (since I couldn't find a decent list of examples out there). Also, at the end I've linked some articles that go into the pros and cons of using SQLite in production, but for a lot of web apps, you don't need the kitchen sink.

First though, a quick SQLite recap:

What is SQLite?

SQLite is a serverless, single-file database. This makes it really lightweight, and easy to set up, especially with AI. It's perfect for today's 'vibe coding' losers (like me?), or for prototyping a project as you don't need to set up a database server. Here it is from the mouth of the horse:

SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine. SQLite is the most used database engine in the world. SQLite is built into all mobile phones and most computers and comes bundled inside countless other applications that people use every day.

Companies like Apple, Adobe, Dropbox, Facebook, are all well-known users of SQLite too, employing it for various services within their products.

Depending on your project, it might also be all you need – especially for web projects as highlighted in this 2021 article from Wesley Apteker-Cassels:

Due to improvements in SQLite, hardware performance, and third-party libraries over the past ~decade, it now makes a lot of sense to use SQLite for many web projects.

Apteker-Cassles demonstrates this in 2021, suggesting now in '25, you might just skip Postgres entirely, and ship with SQLite in production. Pieter Levels has been king of this, running Nomads.com,

I was curious about this, so here's a list of different types of sites that rely on SQLite:

10 SQLite projects in production

Starting with probably the most popular example:

1. Web Directory on SQLite: Nomadlist

Nomads.com is a directory and community for digital nomads that helps users find the best cities to live and work remotely. It uses SQLite as the sole database - no PostgreSQL no MySQL.

• Site type: Directory.

• Built by Pieter Levels.

• Database: 100% SQLite.

• SQLite use: Used for everything from storing city metadata, user profiles, forum posts, and analytics.

• Why: Fast to develop, single file to back up/deploy, and SQLite + cron + static hosting = low ops.

2. Airtable Clone on SQLite: NocoDB

NocoDB is an open-source no-code platform that turns any relational database into a smart spreadsheet interface (similar to Airtable).

The community edition of NocoDB supports SQLite as the primary database

3. Web Analytics on SQLite: GoatCounter

GoatCounter is an open-source, privacy-friendly web analytics platform. Designed for easy self-hosting or use via its official service, it provides basic traffic stats without tracking personal data.

• GoatCounter uses a single-file SQLite database as its default (and primary) data store, but PostgreSQL is optional for larger sites.

• Backups: you run the Go binary on a server or container, and the app can be paired with tools like Litestream for continuous backup of the SQLite file.

• Small to medium = SQLite: This is the default database engine. It's recommended for most small to medium sized sites, like blogs, because it has no dependencies and is easy to set up.

4. Offen (another Web Analytics on SQLite)

Offen is another web analytics platform running on SQLite. Offen is designed to be self-hosted with minimal effort:

4. Password Manager: Vaultwarden

Valutwarden is a lightweight, self-hostable password manager server (using the Bitwarden API). Vaultwarden uses SQLite as its default and recommended database backend for storing vault data:

Vaultwarden can also use SQLite, MySQL/MariaDB, or PostgreSQL as its db, but most deployments use SQLite (since it's default).

5. Blogging Platform: WriteFreely

WriteFreely is a minimalist open-source blogging platform focused on distraction-free writing (it powers the Write.as service).

WriteFreely is written in Go (golang), so it runs anywhere and takes up very few resources — you can even run it on a Raspberry Pi!

WriteFreely supports using SQLite as production database (alternative to MySQL), which means you can self-host a blog on very modest hardware such as Raspberry Pi.

• Decentralized blogging platform (supports ActivityPub).

• Can use MySQL or SQLite as sole DB.

• Many personal and community WriteFreely instances use SQLite only.

6. Video Streaming/Chat server: Owncast

Owncast is a self-hosted live video streaming and chat server (alternative to Twitch).

• Owncast is built in Go and uses SQLite as its core to store stream info, chat, users, etc.

• Owncast also implements ActivityPub for fediverse integratio

7. Kanban App: Kanboard

Kanboard is a lightweight, self-hosted Kanban-style project management tool for tasks and projects. By default, Kanboard uses SQLite.

8. Backend PaaS: PocketBase

PocketBase lets you build apps with user accounts, data storage, and file uploads – all without needing a separate server or complex setup.

• an open-source backend framework and portable database (written in Go) that offers authentication, file storage, and real-time data APIs out of the box.

• essentially a SQLite, self-hosted alternative to services like Firebase. It uses an embedded SQLite database (WAL mode) as its sole production data storepocketbase.io – no other database engines are supported – which greatly simplifies deployment.

• You can run PocketBase on a small VM or in a container with persistent storage; for high availability or backups, many users combine it with replication tools like Litestream.

PocketBase uses embedded SQLite (in WAL mode) and there are no plans for supporting other databases.

For majority of the queries SQLite (in WAL mode) outperforms traditional databases like MySQL, MariaDB or PostgreSQL (especially for read operations).

9. Jobs board: RemoteOK

RemoteOK.com is a greate example aof another high-traffic production site entirely on SQLite. It's one of the most popular remote job boards on the web, featuring job listings for developers, designers, marketers, and other remote roles.

• Also built by Pieter Levels, like Nomad List.

• Uses only SQLite for everything.

• Entire job board is powered by a single SQLite file.

• Pages are pre-rendered via cron jobs and uploaded as static files.

• Uses Git to version the DB and deploy updates.

You can read how it's built here:

How I built Remote | OK and launched it to #1 on Product Hunt

Almost a year a go, I set a goal to launch 12 startups in 12 months [https://levels.io/12-startups-12-months]. The story was covered well by WIRED [http://www.wired.com/2014/08/12-startups-in-12-months/] previously. They’re all MVPs [https://levels.io/how-i-build-my-minimum-viable-products/], built…

10. Another Blogging system: GoBlog

GoBlog is a simple blogging system written in Go that uses SQLite as the main database.

• Site type: blog

• SQLite is the default database.

• Used by its creator for a real blog in production.

• Features: markdown support, webmention, ActivityPub, feeds, etc.

11. Forums: phpBB and MyBB

Run a forum without a separate database server. Both phpbb.com and mybb.com let you run a forum without a separate database server.

Drawbacks of SQLite

One of the most referenced articles on this topic is 'Consider SQLite', which offers a balanced look at the pros and cons of using SQLite for web projects. I would recommend going through that for detailed pros and cons, as well as these thoughtful posts weighing up the trade-offs:

Is it time to ditch MySQL and PostgreSQL for SQLite?

SQLite fits in this logic by providing a simpler alternative to the traditional client-server model of MySQL and PostgreSQL, not without its own set of tradeoffs that can make your project a disaster if not carefully considered.

Why you should probably be using SQLite

Where you store your application data has enormous impacts on your entire application. There are implications on the entire stack based on what you decide to…

SQLite vs PostgreSQL: It depends

From my own perspective, even though I love the lightweight approach of SQLite, I found it really depends on the project.

For example, I was using SQLite for Feed Bagel, which worked great at first – I got the initial version up and running in no time. However, I found the demands of web crawling and concurrent writes had SQLite a bit stretched.

Could I have optimized SQLite further? Probably. But in the end, switching to PostgreSQL gave me the stuff I needed without any friction. I'll keep SQLite for less database intensive projects (most other projects probably).

Comparison SQLite vs PostgreSQL

• Type:

  • SQLite: Embedded serverless single-file DB

  • PostgreSQL: Requires server setup, installation and config

• Storage:

  • SQLite: all in a single .sqlite file

  • PostgreSQL: data stored in a separate managed Database

• Performance:

  • SQLite: Fast for reads and small writes - great for smaller apps

  • PostgreSQL: Better for high-load and write-heavy apps

• Concurrency:

  • SQLite: many readers, 1 writer at a time

  • PostgreSQL: excellent concurrent reads and writes

• Advanced Features:

  • SQLite: limited - no triggers, basic full-text search

  • PostgreSQL: full-text search, triggers, advanced extensions

Anyway, that's enough for today. I hope this post helps with inspiration that you can build stuff with minimal resources where possible.