Postgres is probably enough

Every additional datastore is another thing to back up, monitor, patch, secure, and explain to whoever is on call. That cost is real and recurring, and it is usually accepted far too casually.

Postgres does more than most teams give it credit for.

Things you may not need a second system for

• **Job queues.** `SELECT ... FOR UPDATE SKIP LOCKED` gives you a correct work queue. Good to well past the throughput most applications ever see.
• **Full-text search.** Built-in text search with ranking and stemming handles product catalogues and document search comfortably.
• **Documents.** `jsonb` with GIN indexes covers schemaless data without giving up joins or transactions.
• **Geospatial.** PostGIS is the reference implementation, not a compromise.
• **Time-series.** Native partitioning, or TimescaleDB if you need more.
• **Caching.** Often the query was just missing an index.

When to actually add something

There are real thresholds. Redis earns its place when you need sub-millisecond reads at high concurrency or genuine pub/sub. A dedicated search engine earns its place when relevance tuning becomes a product feature. ClickHouse earns its place when analytical scans dominate.

The test is whether you have measured Postgres failing at the job, not whether a comparison article says something else is faster.

The compounding cost

Two datastores is not twice the operational load, it is more - because now you have consistency between them to worry about. Every dual-write is a chance for the two to disagree, and reconciling them becomes a permanent line item.

Start with one. Add the second when you can point at the graph that justifies it.