Which Database Should You Self-Host? SQLite vs MySQL vs PostgreSQL vs Redis
When you're deploying your own app, the database choice matters more than most people think. It affects performance, ops complexity, backups, and how much memory your server needs.
There are four options you'll run into most often: SQLite, MySQL, PostgreSQL, and Redis. They're not all the same kind of database – and that's the point. Here's when each one makes sense.
SQLite – the zero-ops embedded database
- Best for: small apps, prototypes, CLIs, single-user tools, edge deployments
- Strengths: no server process, single file, zero config, instant setup
- Weaknesses: no concurrent writes, no replication, hard to scale past one instance
SQLite is not a server – it's a library that reads and writes a single file. That makes it perfect for apps where simplicity matters more than scale. If your app has one process writing to the database and modest traffic, SQLite will outperform anything else because there's no network round-trip. The moment you need concurrent writes or multiple app replicas, you've outgrown it.
MySQL – the reliable workhorse
- Best for: web apps, CMS platforms, CRUD-heavy workloads, WordPress/Laravel stacks
- Strengths: fast reads, mature replication, huge ecosystem, low memory footprint
- Weaknesses: weaker JSON support, less strict by default, fewer advanced types
MySQL powers a massive chunk of the internet. It's battle-tested, well-documented, and runs well even on small VPS instances. If you're running a standard web app with mostly reads and simple queries, MySQL will serve you well without hogging resources. Just be aware that its default configs are more lenient than PostgreSQL – silent truncations and implicit type casts can bite you.
PostgreSQL – the feature-rich powerhouse
- Best for: complex queries, data integrity, JSON workloads, GIS, analytics
- Strengths: advanced types (JSONB, arrays, hstore), strong standards compliance, extensions ecosystem
- Weaknesses: higher memory usage, more tuning needed, steeper learning curve for ops
PostgreSQL is the database you pick when correctness and flexibility matter. It handles complex joins, window functions, CTEs, and full-text search natively. The extension ecosystem (PostGIS, pg_cron, pgvector) makes it a Swiss army knife. The trade-off: it's hungrier on resources and rewards careful tuning of shared_buffers, work_mem, and connection pooling.
Redis – the in-memory speed layer
- Best for: caching, sessions, rate limiting, queues, pub/sub, leaderboards
- Strengths: sub-millisecond reads, rich data structures (lists, sets, sorted sets, streams), built-in TTL
- Weaknesses: data must fit in RAM, persistence is optional and lossy, not a primary data store
Redis isn't a replacement for a relational database – it's a complement. Use it for things that need to be fast and can tolerate occasional data loss: session tokens, cache layers, job queues. Redis Streams can even replace simple message brokers. Just don't store your source of truth here – if the server restarts between RDB snapshots, recent writes are gone.
Quick comparison
| Feature | SQLite | MySQL | PostgreSQL | Redis |
|---|---|---|---|---|
| Type | Embedded | Relational server | Relational server | In-memory store |
| Ease of setup | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| Concurrent writes | ❌ Single-writer | ✅ Good | ✅ Excellent | ✅ Very fast |
| Complex queries | Basic | Good | Excellent | N/A (key-value) |
| Memory usage | Minimal | Low–moderate | Moderate–high | High (all data in RAM) |
| Replication | None built-in | Mature | Mature | Built-in |
| Best self-host size | Single instance | Small–large | Medium–large | Any (as cache layer) |
| Persistence | Always (file) | Always (disk) | Always (disk) | Optional (RDB/AOF) |
So which one should you choose?
- Building a prototype or CLI tool? → SQLite
- Running a standard web app? → MySQL
- Need complex queries, JSONB, or extensions? → PostgreSQL
- Need a fast cache, session store, or queue? → Redis
Most real-world apps end up using two: a relational database (MySQL or PostgreSQL) for your data, and Redis for caching and sessions. That's not overkill – it's the right tool for each job.
Self-hosting these databases
Running databases on a VPS means managing backups, updates, and disk space yourself. It's doable, but it's one more thing to maintain.
On Hostim.dev, MySQL, PostgreSQL, and Redis are built in – provisioned alongside your app with metrics and no extra config. Paste a docker-compose.yml and your database is ready.