There's a version of every product architecture that has five data systems in it: a relational database, a document store, a queue, a cache, a search engine. Each one is another thing to deploy, secure, back up, monitor, and pay for — and another thing the next engineer has to learn before they can help you.
PostgreSQL, used well, covers most of that list for most products. JSONB columns handle the document-shaped data. Full-text search handles the search box. LISTEN/NOTIFY and a jobs table handle background work at the scale most businesses operate at. Row-level security handles multi-tenant isolation without scattering authorization logic through application code.
We add Redis when there's a real caching or realtime case. Our multiplayer games will need it; most dashboards don't. We'd add a dedicated search engine or analytics store when the numbers demand it. Specialty tools are good tools. Every one of them should be earned by a measured need before it enters the architecture.
This bias shows up in what we hand over: a system with one database is a system your accountant-turned-admin can understand the backup strategy for. Boring architecture is a feature. It's also cheaper to run every single month.
When a client comes to us with a five-system diagram for a two-table product, the most valuable engineering we do is subtraction.
Building something this applies to?