Databases
How to choose between Postgres, Redis, and SQLite for product workloads.
When to use this page
- You need to choose a primary data store for a new product.
- You want to know when to add Redis as a secondary store.
- You are considering SQLite for low-ops or mobile-oriented workloads.
Prerequisites
- Basic understanding of your read/write patterns.
- Rough estimate of expected concurrency and data growth.
- Decision whether data must be shared across multiple app instances.
Quick comparison
| Option | Best for | Tradeoff |
|---|---|---|
| Postgres | Primary product data, long-lived records, reporting foundations | More operational overhead than SQLite |
| Redis | Cache, queues, short-lived and high-throughput data | Not a system-of-record database |
| SQLite | Small apps, internal tools, mobile/embedded data | Limited write concurrency and scale |
Postgres (default)
Postgres is our default for most backend applications because it balances reliability, strong data integrity, and long-term maintainability.
Use Postgres when you need:
- Relational data with constraints and transactions.
- Mature ecosystem, migration tooling, and query flexibility.
- JSON fields without introducing a separate NoSQL database.
Redis
Redis is usually added next to Postgres, not instead of it.
Use Redis when you need:
- Low-latency cache layers to reduce database load.
- Queues/background workers and short-lived state.
- Rate limiting or fast temporary counters.
Avoid Redis as your only database for business-critical records unless you explicitly design for durability constraints.
SQLite
SQLite is a strong option for simple single-writer workloads and mobile/local-first storage.
Use SQLite when you need:
- Minimal operational overhead.
- Fast setup with a single file on disk.
- Local storage for desktop/mobile/offline-first scenarios.
Recommended baseline
- Start with Postgres for most cloud products.
- Add Redis only when a clear cache/queue need appears.
- Choose SQLite for intentionally small or local-first systems.
Verify your decision
- Confirm the selected database matches write concurrency needs.
- Confirm your backup and restore plan exists.
- Confirm the team has operational ownership for the chosen stack.