# Redis and PostgreSQL for Trading

> How Redis and PostgreSQL work together in trading systems: Redis for live prices, caches and state, PostgreSQL for durable orders, fills and history.

Source: https://learn.tradelabsai.com/infrastructure/redis-and-postgresql-for-trading/  
Track: Trading Infrastructure · Level: Advanced · Updated: 2026-10-03  
Publisher: TradeLabs AI (https://tradelabsai.com). Education, not financial advice.  
Cite as: TradeLabs Learn, "Redis and PostgreSQL for Trading", https://learn.tradelabsai.com/infrastructure/redis-and-postgresql-for-trading/

Two databases appear in a huge number of trading setups, from hobby bots to production services: Redis and PostgreSQL. They solve different problems. Redis is an in memory data store, extremely fast and ideal for the latest prices, caches, counters and short lived state. PostgreSQL is a durable relational database, ideal for orders, fills, account history and anything that must never be lost. Used together, they give a system both speed and a reliable record.

## Comparing the two

| | Redis | PostgreSQL |
|---|---|---|
| Storage | In memory, with optional persistence | On disk, fully durable |
| Speed | Sub millisecond reads and writes | Fast, but slower per operation |
| Data model | Keys with strings, hashes, lists, sets, sorted sets, streams | Tables with SQL, constraints and transactions |
| Strength | Live state, caching, pub sub, rate limits | Accuracy, queries, history, integrity |
| Risk | Data can be lost if persistence is off or misconfigured | Slower under very high write rates |

## Typical uses of Redis in trading

- **Latest price per symbol,** shared between processes.
- **Caches** of slow API responses or reference data.
- **Pub sub** to push updates to dashboards. See [Message Queues](https://learn.tradelabsai.com/infrastructure/message-queues/).
- **Rate limit counters** for API usage or order throttles. See [Risk Controls and Kill Switches](https://learn.tradelabsai.com/algo-trading/risk-controls-and-kill-switches/).
- **Locks** so only one bot instance trades. See [Fault Tolerance, High Availability and Redundancy](https://learn.tradelabsai.com/infrastructure/high-availability/).
- **Leaderboards and rankings** with sorted sets.

```python
import redis
r = redis.Redis()
r.hset("px:BTCUSDT", mapping={"bid": 64250.1, "ask": 64250.5, "ts": 1790000000123})
latest = r.hgetall("px:BTCUSDT")
```

## Typical uses of PostgreSQL in trading

- **Orders, fills and positions** with full history. See [Database Design for Market Data](https://learn.tradelabsai.com/programming/database-design-for-market-data/).
- **Account and cash ledgers** with exact decimal values.
- **Reference data:** instruments, tick sizes, trading calendars.
- **Bars and research data** at moderate scale, or large scale with the TimescaleDB extension. See [Data Storage, Compression and Caching](https://learn.tradelabsai.com/programming/data-storage/).
- **Reporting and reconciliation** queries. See [SQL for Trading Data](https://learn.tradelabsai.com/programming/sql-for-trading-data/).

Transactions are PostgreSQL's key strength: recording a fill and updating a position happen together or not at all, so the books never disagree with themselves.

**Example: Splitting responsibilities**
A crypto bot receives about 50 price updates per second. It stores the latest bid and ask for each symbol in Redis, where the strategy and a web dashboard read them instantly. When the bot places an order, it writes the order to PostgreSQL before sending it, then records each fill and the updated position in one transaction. One night the server reboots. Redis restarts with stale prices, which the bot ignores until fresh data arrives. PostgreSQL still holds every order and fill, so the bot reconciles with the exchange and resumes with correct positions. See [Trade Accounting and Reconciliation](https://learn.tradelabsai.com/industry/trade-reconciliation/).

## Persistence settings in Redis

| Option | Behaviour |
|---|---|
| No persistence | Fastest; data lost on restart |
| RDB snapshots | Periodic snapshots; recent changes can be lost |
| AOF (append only file) | Logs every write; configurable sync frequency |

Treat Redis as a fast cache and live state store unless you have deliberately configured and tested persistence. Anything financial and important belongs in PostgreSQL too.

## Performance tips

- **Index PostgreSQL tables** on the columns you filter by, such as (instrument_id, ts).
- **Batch inserts** of market data instead of one row at a time.
- **Use connection pooling** for many short connections.
- **Set Redis memory limits** and an eviction policy for caches.
- **Monitor both:** memory, connections, slow queries and replication lag. See [Monitoring and Logging Systems](https://learn.tradelabsai.com/infrastructure/monitoring-and-logging-systems/).

## Alternatives

SQLite works well for a single bot on one machine with no server to manage. Specialist time series and columnar databases handle very large tick datasets. Managed cloud versions of Redis and PostgreSQL remove maintenance work at extra cost.

## Frequently asked questions

### Why use Redis in a trading system?

For very fast access to live prices, caches, counters, locks and pub sub messaging shared between processes.

### Is PostgreSQL good for trading data?

Yes. It is reliable for orders, fills and accounts and handles moderate market data well, with extensions such as TimescaleDB for larger time series.

### Can I use Redis as my only database?

It is risky for important records, because in memory data can be lost if persistence is not configured carefully; keep durable records in a database like PostgreSQL.

Next, learn how to watch all of these systems in [Monitoring and Logging Systems](https://learn.tradelabsai.com/infrastructure/monitoring-and-logging-systems/).

## Continue learning

- Next lesson: [Monitoring and Logging Systems](https://learn.tradelabsai.com/infrastructure/monitoring-and-logging-systems/)
- Previous lesson: [Message Queues](https://learn.tradelabsai.com/infrastructure/message-queues/)
- Related: [Message Queues](https://learn.tradelabsai.com/infrastructure/message-queues/): Message queues pass market data, signals and orders between trading components. Learn pub sub and queues, tools like Kafka, Redis and ZeroMQ, and design trade offs.
- Related: [Database Design for Market Data](https://learn.tradelabsai.com/programming/database-design-for-market-data/): How to design database tables for bars, ticks, symbols, orders and fills. Learn keys, indexes, partitioning, data types and how to avoid common design mistakes.
- Related: [SQL for Trading Data](https://learn.tradelabsai.com/programming/sql-for-trading-data/): Learn the SQL queries traders use most: filtering bars, aggregating trades into candles, joining fills to orders, window functions for returns and daily P&L.
- Related: [Data Storage, Compression and Caching](https://learn.tradelabsai.com/programming/data-storage/): Compare ways to store market data: CSV, Parquet, HDF5, PostgreSQL, time series and columnar databases. Learn compression, partitioning and how to choose.
- Related: [Fault Tolerance, High Availability and Redundancy](https://learn.tradelabsai.com/infrastructure/high-availability/): High availability keeps trading systems running through hardware, network and software failures. Learn redundancy, failover, avoiding split brain and testing it.