In the architecture diagram delivered by the development company, five boxes stand in a row: Application, PostgreSQL, Redis, Job Execution Infrastructure, Full-Text Search Engine. Each appears to be a reasonable choice.
The catch comes post-delivery. Operating this architecture requires someone who can define monitoring metrics, manage backups, track version upgrades, and isolate failures across all five components. If no such person exists internally, the system becomes untouchable the moment the maintenance contract expires.
Discussions on technology selection tend to revolve around "will it perform?", but in small-to-medium systems, what matters first is "who can fix it when it breaks?" Taking this as a starting point, we examine whether decisions can be made toward simplifying architecture.
What increases when you add one piece of middleware
The cost of deciding to "bring in Redis" is not merely server fees. What actually increases is the following operational workload:
- One more monitoring target is added. You need to define what constitutes "healthy," establish thresholds, and configure alert destinations. Adding components without these definitions creates elements that can go down without anyone noticing (Monitoring begins with defining "healthy")
- One more backup and recovery procedure is added. Whether the assumption that "it's just a cache, so data loss is fine" truly holds cannot be known without auditing the implementation
- One more stream of version upgrades to track. You increase the number of components for tracking end-of-life dates and security patches
- Failure isolation becomes one tier more complex. Determining whether the cause of "slowness" is the app, database, cache, or network requires cross-referencing logs across each layer
- Hiring and handoff constraints increase by one. When transitioning maintenance to another vendor, the pool of capable companies narrows
The fifth point impacts small and medium-sized businesses the hardest. The more architectural components there are, the harder it becomes to find the next person to take over.
What PostgreSQL can substitute for
In recent years, utilizing PostgreSQL's native capabilities has been widely discussed as a practical option for "thinking before adding." What it can realistically substitute for includes the following:
Job queues. By using SELECT ... FOR UPDATE SKIP LOCKED, you can treat tables directly as queues. This mechanism allows multiple workers to share workloads without competing for the same rows, representing an approach proven in production. Standard practice is to use established libraries like pg-boss or river rather than writing your own. Typical asynchronous tasks—such as sending emails, generating reports, and invoking external APIs—are well within this capability.
Caching. Using unlogged UNLOGGED tables provides faster speeds than regular tables. Unless sub-millisecond response times are a hard requirement, there are many scenarios where Redis can be omitted.
Full-text search. PostgreSQL includes built-in full-text search features. While handling Japanese requires additional configuration, for on-site search or filtering in admin dashboards, spinning up a dedicated search engine is unnecessary.
Job scheduling. Requirements extending beyond simple recurring execution can be handled through extensions like pg_timetable.
In short, up to three boxes from the opening diagram can potentially be eliminated. Downsizing to just the application and PostgreSQL leaves only a single pipeline for monitoring, backups, and handoffs.
Where the line of what cannot be substituted lies
On the other hand, it is not a matter of "Postgres is fine for everything." The boundary is clear.
| Requirement | Is Postgres sufficient? |
|---|---|
| Typical business system queues, caching, and search | Sufficient |
| Sub-millisecond cache responses | Redis required |
| Processing millions of messages per second | Kafka required |
| Distributed search involving complex linguistic analysis | Elasticsearch required |
Extreme throughput or extreme specialization. Unless your requirements match one of these two, the justification for introducing dedicated middleware is weak. In business systems for small and medium-sized enterprises or custom development projects, hitting these two criteria is relatively rare.
Note that there are caveats when using Postgres as a queue. Because this usage repeatedly creates and deletes massive volumes of rows, tables will bloat if dead tuple cleanup cannot keep pace. The reason to use established libraries is precisely because they account for these operational pitfalls. If you implement it from scratch, you will have something that works right away, but slows down six months later.
Arguments for consolidation are also emerging
The movement toward reducing architectural components is also appearing on the database product side. Harper 5.2, released in August 2026, takes a stance against architectures that separate databases, caches, and job execution into distinct systems, promoting a design that co-locates application code and data within the same runtime.
In benchmarks published by the company, in-process data access is clocked at around 0.4 milliseconds, compared to approximately 3 milliseconds when fetching across a network to a separate tier. While figures from vendor-run benchmarks must be treated with care, the structural reality that "separating tiers incurs network overhead every time" remains unchanged.
To separate or to consolidate: this is less a conflict of technical trends than a matter decided by available operational headcount and maintenance handoff assumptions. In an organization with multiple dedicated infrastructure engineers, separating tiers offers greater flexibility; however, in an organization with only a single IT team member or relying entirely on outsourced vendors, consolidation is what endures.
Two questions to ask during the ordering stage
Because evaluating the technical validity of an architecture is difficult for clients, asking the following two questions provides clarity for making decisions:
1. "If we were to eliminate one component from this architecture, which one would it be, and why?"
If the rationale for retaining it is concrete ("because handling X requests per second is a hard requirement"), it is valid. If the answer is "because it's standard practice" or "because it will be needed when scaling in the future," it is a choice that did not stem from current requirements. Adding components when actually needed later is far cheaper than continuously operating unused ones.
2. "After delivery, what tasks will be required to operate this, broken down by component?"
Monitoring, backup, and upgrade tasks will be enumerated for as many boxes as there are. Reviewing this before finalizing the scope and pricing of the maintenance contract makes negotiations concrete. If a clear breakdown does not emerge, the architecture likely was not designed with operations in mind.
A similar dynamic arises when designing asynchronous processing to "guarantee exactly-once execution." Deciding whether to add external mechanisms or rely on database features is covered in Guaranteeing processing reliability with Postgres and SQLite.
What to do next
If you already have a system running in production, open the architecture diagram and check for each component: "Did anyone perform maintenance work on this last month?" Components that no one has touched might not just be running smoothly—they may be completely abandoned. Middleware frozen on outdated versions is often discovered this way.
If you are commissioning development in the future, pose the two questions above during the requirements definition phase. Discussing reductions after architecture is finalized triggers design rework, which drives up costs.
Reviewing architectural validity, auditing existing operational burdens, and revising the scope of maintenance contracts are handled through GleamHub's Development, AI, and Automation consultations. Because viable options depend on your current architecture and internal operational capabilities, please consult with us individually. Feel free to reach out via Contact Us.
Sources
- PostgreSQL for Everything — Raphael Bauer
- Harper Argues Against the Multi-System Stack and Releases 5.2 — InfoQ
- Harper 5.2: More Throughput per Node, Fewer Systems Around It — Harper
- SELECT — PostgreSQL Documentation（FOR UPDATE / SKIP LOCKED）
- Potential Consequences of Using Postgres as a Job Queue — Microsoft Community Hub
