Every side project starts with a database decision, and most developers overthink it. I’ve seen weekend projects stall for days because someone spent too long debating PostgreSQL vs MongoDB instead of writing code. Here’s a practical guide based on what actually matters when you’re building something new.

Start With SQLite (Seriously)

SQLite is the most deployed database in the world, and it’s probably the right choice for your side project. It runs as a single file, requires zero configuration, and handles more concurrent users than you think.

For a typical side project — a personal tool, a small SaaS, a content site — SQLite handles thousands of concurrent readers without breaking a sweat. The write throughput is limited to one writer at a time, but with WAL (Write-Ahead Logging) mode enabled, reads don’t block writes and vice versa.

The tooling has improved dramatically. Libraries like better-sqlite3 for Node.js and rusqlite for Rust provide synchronous APIs that are faster than network-based alternatives because there’s no TCP overhead. Turso and LiteFS have made SQLite viable for distributed deployments.

I’ve been running a side project with 2,000 daily active users on SQLite deployed to a single Fly.io machine. The 95th percentile query time is under 2 milliseconds. No connection pooling to manage, no database server to monitor, no credentials to rotate.

When PostgreSQL Makes Sense

PostgreSQL is the correct choice when your data model demands it. Specifically:

• You need complex joins across many tables
• You’re doing full-text search and don’t want a separate search service
• You need JSONB columns with indexed queries
• You require row-level security or advanced access control
• Your application will have multiple services writing concurrently

Postgres is also the safe default for any project you expect to scale beyond a single server. The migration path from SQLite to Postgres is well-documented, but it’s easier to start with Postgres if you know you’ll need it.

The managed Postgres offerings have gotten remarkably good. Neon’s serverless Postgres scales to zero, meaning you pay nothing when your side project is idle. Supabase wraps Postgres with auth, real-time subscriptions, and a REST API. These services eliminate the main drawback of Postgres for side projects: operational overhead.

MySQL in 2026

MySQL still powers a huge portion of the internet, but for new projects, it’s hard to recommend over PostgreSQL. Postgres has caught up and surpassed MySQL in most areas: JSON support, window functions, CTEs, and general SQL standard compliance.

The one scenario where MySQL might make sense is if you’re deploying to a shared hosting environment that only offers MySQL, or if you’re building on top of PlanetScale’s distributed MySQL platform. PlanetScale’s branching workflow is genuinely excellent for schema migrations.

If you’re already experienced with MySQL and don’t need Postgres-specific features, it’s fine. But if you’re choosing fresh, Postgres gives you more room to grow.

MongoDB: Be Honest About Your Needs

MongoDB gets a lot of criticism, some deserved and some not. The document model is genuinely useful when your data is hierarchical and doesn’t fit neatly into tables. Storing a complex product catalog with varying attributes across categories is a legitimate use case.

The problems arise when developers choose MongoDB because “it’s easier” and then discover they need to do relational queries. Adding $lookup stages to aggregation pipelines to simulate joins is slower and more complex than just using a relational database.

My rule of thumb: if you can draw your data model as a set of related tables on a whiteboard, use a relational database. If your data is genuinely document-shaped — nested, variable-structure, and primarily queried as complete units — MongoDB is worth considering.

The New Contenders

A few newer options deserve mention. DuckDB is outstanding for analytical queries on local data. It’s like SQLite but optimised for OLAP workloads. If your side project involves processing CSV files, log analysis, or data exploration, DuckDB is worth a look.

SurrealDB attempts to combine document, graph, and relational models in one system. It’s ambitious and the developer experience is interesting, but I’d wait for the ecosystem to mature before betting a project on it.

Drizzle ORM and Prisma have also changed the conversation by making the ORM layer so pleasant that the underlying database choice matters less from a developer experience perspective. Both support SQLite, Postgres, and MySQL with the same TypeScript API.

The Decision Framework

Ask yourself three questions:

1. Will this project have multiple servers writing to the database? If no, start with SQLite. If yes, use Postgres.

2. Is my data genuinely document-shaped? If yes and you don’t need cross-document queries, consider MongoDB. Otherwise, relational.

3. Do I need features specific to a particular database? Postgres extensions, MySQL replication topology, MongoDB’s aggregation pipeline — if a specific feature drives the choice, follow it.

For everything else, pick the database you know best. Developer familiarity beats theoretical performance advantages for side projects. Ship first, optimise later.