Use SQLite. It needs no server, costs nothing, survives your project being idle for six months, and handles far more traffic than a side project will ever see. Choose Postgres instead if you need extensions like pgvector or PostGIS, or if you're deliberately practising for production work.
Editorial judgement last reviewedThe database question kills more side projects than any other technical decision, because it's usually answered as though the project will need to scale, and then the project spends its short life paying for complexity it never uses.
A side project has a specific profile: no traffic, long idle periods, one developer, and a hard requirement that it still works when you come back to it in eight months. Optimising for a million users is optimising for something that will not happen. Optimising for it still being alive next year is optimising for the thing that decides whether the project survives.
Our database comparison ranks nothing, these are three good engines with different deployment models, but for this specific use case there is a clear answer, and it's the one most developers skip past.
We ranked for a side project, which weights very differently from production.
Setup cost. How long from decision to first query. Anything measured in hours is a tax on momentum you can't afford at the start of a project.
Ongoing cost, in dollars and in attention. Free tiers that pause after a week of inactivity are a specific hazard for projects you touch on weekends.
Resilience to neglect. Whether it still works after six months untouched, without a version upgrade, a re-authentication or a restore.
Backup simplicity, because you will not set up a sophisticated backup pipeline for a side project and pretending otherwise is how projects lose data.
Upgrade path, if the project unexpectedly becomes real.
No server, no connection string, no account, no free tier to expire. The database is a file next to your application, and queries take microseconds because there's no network in the path. You can back it up by copying a file, inspect it with any SQLite
browser, and commit a seed version to the repository.
Nothing pauses it, nothing expires it, and nothing requires you to log into a dashboard to reactivate it after three months away. That resilience to neglect is worth more to a side project than any performance characteristic.
Modern deployment makes it production-viable too: WAL mode handles concurrent reads comfortably, and Litestream streams the write-ahead log to object storage for point-in-time recovery at the cost of an S3 bucket.
Declare STRICT tables so the dynamic typing doesn't surprise you, and remember there's one writer at a time, which is not a constraint a side project will notice.
The right choice for two specific reasons. First, extensions: pgvector for embeddings, PostGIS for geospatial, proper full-text search, pg_cron for scheduling. If your side project is an AI thing that needs vector search at any real scale, this is the shortest path.
Second, deliberate practice. If the project exists partly to keep your production skills sharp, or to become something real, starting on Postgres
removes a migration later and Postgres is the most transferable database skill there is.
Managed free tiers are generous, Supabase
and Neon both carry a side project comfortably, and Neon's scale-to-zero suits intermittent use particularly well.
The hazard is the free tier itself: projects that pause after inactivity, then need reactivating. That's the specific way side projects on managed Postgres die quietly.
Embedded like SQLite, but column-oriented and built for analytics. If your side project is chewing through CSVs, Parquet files or a few million rows of scraped data, DuckDB
will run aggregate queries orders of magnitude faster than a row-store, in-process, with no server.
It reads Parquet and CSV directly, so a lot of projects skip the loading step entirely and query files where they sit.
Not a transactional application database, use it alongside SQLite rather than instead of it if your project has both a user-facing side and an analytical one. For a data exploration project, it's the most fun option on this list.
Fine, fast and well understood, but there's rarely a positive reason to choose it for a new side project in preference to the options above. The case for it is environmental: you're using WordPress, a PHP framework, or a legacy tool that assumes MySQL
, or you already have a MySQL server running and adding a database to it is free.
Cheap managed hosting is the one genuine advantage, the MySQL market is more commoditised than the Postgres one, so the floor price is lower.
If you're choosing freely, choose SQLite for simplicity or Postgres for capability.
The most common way a side project database fails isn't load. It's that you didn't touch the project for two months, the free tier paused the instance, and coming back means logging into a dashboard, reactivating, discovering the password manager entry is stale, and losing the thirty minutes of enthusiasm that brought you back in the first place.
Managed free tiers pause idle projects, expire trial credits, require periodic re-authentication and occasionally force version upgrades. Each is individually reasonable and collectively a tax on exactly the usage pattern a side project has.
SQLite has none of this because there's nothing to pause. The file is in your repository or on your server, and it works the same on the day you return as on the day you left.
If you do want managed Postgres, pick a provider whose scale-to-zero resumes automatically on connection rather than one requiring manual reactivation, the difference is invisible when you choose and decisive six months later. And keep the connection string in the repository's environment example, so future-you doesn't have to go looking.
The fear behind this question is starting on SQLite and hitting a wall. Worth being concrete about where that wall actually is.
SQLite allows one writer at a time. In WAL mode readers don't block the writer and vice versa, so read-heavy applications scale a long way, on modern hardware, thousands of reads per second and hundreds of writes without complaint. Most applications that developers assume need a database server do not.
The genuine ceilings are: sustained heavy concurrent writes; needing multiple application servers writing to the same database, which a network filesystem cannot safely provide; and needing the database on different hardware from the application. If you hit those, you have a real product and migrating is a good problem.
The migration itself is a schema translation and a data copy, a day or two of work, well-trodden, with tooling. That's a far smaller cost than running managed Postgres for a year on a project that never got users.
If you'd rather not migrate at all, libSQL and Turso keep SQLite's model while adding replication and a hosted service, which is a gentler step than a full engine change.
No. It's the most widely deployed database engine in the world, exhaustively tested, and entirely capable of running a production web application on a single server. The single-writer constraint is real; the assumption that it's a toy is not.
Copy the file when nothing is writing, or use Litestream to stream the write-ahead log continuously to object storage for point-in-time recovery. The second option costs a few cents a month and takes ten minutes to set up.