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) |
Performance and resource footprint
Raw speed is the wrong question to ask on its own – these databases do different jobs. But people search for "redis vs sqlite performance" for a reason, so here is the honest version.
For a single simple read, the ranking is roughly:
- SQLite – microseconds. It runs inside your app process, so there is no network at all.
- Redis – sub-millisecond, but over the network. Fastest thing you can query remotely.
- MySQL / PostgreSQL – low single-digit milliseconds for an indexed query over localhost.
So yes, SQLite can be faster than Redis for a single-process app, because it skips the network entirely. And Redis is faster than MySQL or PostgreSQL for simple key lookups. But this only matters at high request rates – for most apps the difference is noise next to a missing index or an N+1 query.
Memory is where the real self-hosting difference shows up:
| Resource | SQLite | MySQL | PostgreSQL | Redis |
|---|---|---|---|---|
| Baseline RAM | ~0 (in-app) | 256–512 MB | 512 MB–1 GB | Dataset size + overhead |
| Scales with | File size | Connections | Connections | Total data (all in RAM) |
| Disk | One file | Data + binlog | Data + WAL | Optional snapshot |
The takeaway: SQLite costs almost nothing, MySQL is the lightest server, PostgreSQL wants a bit more room to breathe, and Redis memory grows with your data – budget for the whole dataset plus headroom.
For a deeper look at real numbers, see our Postgres benchmark: RDS vs Hostim vs self-hosted.
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.
Frequently asked questions
Is SQLite faster than Redis?
For a single-process app, yes – SQLite reads run inside your process with no network, so they finish in microseconds. Redis is faster than SQLite once you need many processes or replicas hitting the same data, because SQLite allows only one writer at a time.
Can PostgreSQL replace Redis?
Partly. PostgreSQL has LISTEN/NOTIFY for pub/sub and unlogged tables for fast throwaway data, so a small app can skip Redis. But it won't match Redis for sub-millisecond caching or high-rate counters. Add Redis when your database spends most of its time answering the same cheap queries.
Should I use MySQL or PostgreSQL for a new project?
Pick PostgreSQL if you want strict data handling, JSONB, or extensions like PostGIS and pgvector. Pick MySQL if you run a standard web stack (WordPress, Laravel) and want the lightest server footprint. Both are safe long-term choices.
Is Redis a database or a cache?
Both, but treat it as a cache by default. Redis can persist to disk, but a restart between snapshots loses recent writes. Keep your source of truth in a relational database and use Redis for speed.
Should I self-host PostgreSQL or use a managed service like Supabase?
It depends on how much ops work you want to own. We break the trade-offs down in self-hosting Postgres vs Supabase.
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.