How to Choose a Database for Your Side Project
A practical guide to picking between SQL, NoSQL, and embedded databases based on workload, scale, and team size.
When you are building a side project, the database decision often feels bigger than it is. You read about PostgreSQL, MongoDB, SQLite, and Redis, and each one has passionate advocates. The truth is simpler: most side projects do not need a database at all, and the ones that do usually need the most boring option available.
Start with the shape of your data
Before choosing a database, ask what your data actually looks like. If your records have a fixed set of fields that relate to each other, a relational database is a natural fit. If your data is a loose collection of documents that vary in structure, a document store may feel more comfortable.
The key insight is that your choice should follow the shape of your data, not the hype around a particular tool.
When to use PostgreSQL
PostgreSQL is the default choice for most new projects. It handles relational data, JSON, full-text search, and geospatial queries. It is reliable, well-documented, and runs everywhere.
If you are unsure what to pick, pick PostgreSQL. It is rarely the wrong answer.
When to use SQLite
If you have fewer than a hundred thousand rows and a single writer, SQLite is probably enough. It is a file, requires no server, and is incredibly fast for read-heavy workloads.
Many side projects start with SQLite and never outgrow it. You can always migrate later.
When to use a document store
Document stores like MongoDB shine when your records have unpredictable or deeply nested structures. If you are storing user-generated content that varies wildly, a document model can save you from painful migrations.
The trade-off is that you give up joins and transactions. Make sure you actually need the flexibility before paying that cost.
A decision framework
- Do you need to relate records? Use a relational database.
- Is your data mostly read, small, and single-writer? Use SQLite.
- Do your records vary in structure? Consider a document store.
- Do you need sub-millisecond caching? Add Redis on top, not instead.
The boring choice is usually the best
The most expensive thing in a side project is your attention. A database that you already understand, that has boring documentation, and that never surprises you is worth more than a shiny tool that demands constant maintenance.
Choose the boring option. Ship your project. Revisit the decision only when you have real evidence that you need to.