Should you use Redis or a database for crypto market data?

Short version: you use both — Redis for the hot, real-time layer and a database for the durable, queryable layer. They solve different problems, and "crypto market data" spans both.

Redis (in-memory)

• Great for: latest tick prices, order books, WebSocket feeds, rate limiting, short-lived caches, pub/sub fan-out of live updates to many subscribers.
• Millisecond reads, sub-millisecond writes, naturally fits the push model of exchange feeds.
• The catch: it's memory-bound, and everything in it is gone on restart unless you enable persistence (even then, it's not a great source of truth). No SQL, limited query patterns.

Database (Postgres / TimescaleDB / ClickHouse / etc.)

• Great for: historical candles, trade history, backtesting data, analytics, reporting, "what was BTC's price on this date".
• TimescaleDB (Postgres extension) is a very common choice for time-series crypto data; ClickHouse is the heavy-duty option for massive append-heavy workloads.
• The catch: not built for sub-millisecond reads on the hot path or streaming fan-out.

The typical architecture

Exchange WebSocket → Redis (live price, order book, pub/sub) 
                          ↓
                     Worker writes snapshots/ticks
                          ↓
                TimescaleDB/Postgres (history, queries)

Redis serves the live app/users; the DB is what you query for history, charts, and analysis. The worker that bridges the two is where most of the real engineering goes (dedup, batching, normalization).

A few practical points for crypto specifically

• Crypto data is high-frequency and messy — order books update dozens of times a second per pair, and different exchanges don't even format the same fields the same way. Normalize once at ingestion, not in queries.
• If you need historical backtesting, the DB is non-negotiable — you can't answer "what would this strategy have returned" from Redis memory.
• Storage can blow up fast. Per-trade data for many pairs across many exchanges is terabytes over time, so decide your granularity (tick-level vs. 1s/1m candles) early — you can aggregate down but never recover raw data you didn't keep.
• Time-to-live (TTL) in Redis for a hot cache on top of the DB is a perfectly valid middle ground if you don't need true sub-second latency.

If you tell me the scale you're targeting (a hobby feed vs. production multi-exchange service) and what you're building (live dashboard, backtester, trading bot), I can get more specific — but the general rule holds: Redis for the live layer, a time-series DB for the durable layer, and a sync job between them.