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#

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.
• Rate limit counters for API usage or order throttles. See Risk Controls and Kill Switches.
• Locks so only one bot instance trades. See Fault Tolerance, High Availability and Redundancy.
• Leaderboards and rankings with sorted sets.

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.
• 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.
• Reporting and reconciliation queries. See 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.

Persistence settings in Redis#

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.

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.