The Reflex Problem: Why Engineers Grab New Tools Before Thinking
Engineers don’t pause to think. They pattern-match. A new problem surfaces and the instinct kicks in immediately: find the named tool that sounds like it fits, add it to the stack, ship it. Eduardo Bellani calls this “architectural cargo culting” — borrowing the shape of a solution without understanding the substance beneath it.
The pattern plays out in predictable ways. Application running slow? Reach for Redis. Need an audit trail? Someone suggests an event sourcing database or a temporal data store. The problem statement barely gets finished before the tool nomination starts. Nobody asks whether the existing infrastructure already handles it. Nobody checks whether PostgreSQL — already running, already trusted, already paid for — covers the use case completely.
Familiarity bias drives most of these decisions. When a tool has enough conference talks, enough Stack Overflow answers, and enough LinkedIn endorsements behind it, it starts to feel like the safe choice. Teams default to what the community recognizes rather than what the problem actually demands. Safety, in this context, means social safety — the ability to justify the decision to a manager or a peer review — not operational safety.
The costs don’t show up immediately. One extra service looks manageable. One additional infrastructure dependency feels routine. But each new component added on top of PostgreSQL introduces its own failure modes, its own scaling behavior, its own monitoring requirements, its own on-call burden. The stack grows, the operational surface expands, and the team that made those early tool choices has usually moved on by the time the compounding debt comes due.
This is the core problem with reflexive tool adoption in software engineering: the decision feels low-stakes in the moment because the consequences are deferred. Adding a Redis instance for caching or a dedicated message queue for background jobs doesn’t break anything today. It just quietly raises the floor on complexity — the number of moving parts, the headcount needed to maintain them, and the entropy that accumulates inside systems that nobody fully understands anymore.
The Familiar Culprits: When ‘Best Practice’ Becomes Unexamined Habit
Eduardo Bellani names two scenarios that will make most backend engineers wince in recognition. First: the team needs an audit trail, so someone proposes spinning up a dedicated temporal database or wiring in an event-sourcing system. Second: the application feels slow, so someone reaches for Redis or another in-memory key-value store before anyone has looked at a query plan. Both moves get scheduled, budgeted, and deployed. Neither one prompts the obvious question — does PostgreSQL already handle this?
The answer, repeatedly, is yes. PostgreSQL ships with native support for temporal data modeling, row-level versioning, and append-only table patterns that cover the overwhelming majority of audit logging requirements. Its indexing capabilities, connection pooling options, and query optimizer mean that a slow application is usually a misconfigured one, not a cacheless one. Adding Redis before fixing a missing index is not optimization — it is avoidance wearing the costume of performance engineering.
What makes these two patterns so persistent is their surface legitimacy. Reaching for a purpose-built event-sourcing database signals architectural seriousness. Deploying a caching layer signals scalability awareness. Both moves pattern-match to things senior engineers have praised in conference talks and blog posts. The decision feels responsible precisely because it mirrors what high-performing teams at well-known companies have done — which is exactly what Bellani means by architectural cargo culting.
The damage accumulates quietly. Each additional data store multiplies operational surface area: separate deployment configurations, monitoring pipelines, backup strategies, failure modes, and the cognitive load carried by every engineer who joins the team afterward. PostgreSQL sits at the center of the stack either way, because its reputation for reliability makes skipping it unthinkable. So the result is not Redis instead of PostgreSQL — it is Redis on top of PostgreSQL, layering complexity onto a system that already had the capability to solve the problem.
The habit is not stupidity. It is pattern recognition running ahead of first-principles thinking, and in database architecture decisions, that gap has a real cost.
What PostgreSQL Actually Does That Most Engineers Don’t Realise
PostgreSQL has been in active development for over 35 years. In that time, it has grown from a relational database into something most engineering teams have never fully mapped: a general-purpose data platform capable of replacing several categories of specialist infrastructure that teams routinely bolt on top of it.
Take caching. Redis gets added to stacks constantly, yet PostgreSQL’s unlogged tables offer in-memory-speed writes without durability overhead, and its connection pooling through PgBouncer cuts the latency that makes teams reach for a cache in the first place. Take messaging. Kafka and RabbitMQ dominate job queue conversations, but PostgreSQL’s LISTEN/NOTIFY mechanism delivers pub/sub messaging between processes with zero additional infrastructure. pg_cron handles scheduled task execution inside the database itself. For teams running high-throughput event pipelines at modest scale, that eliminates an entire service.
Document storage is another blind spot. PostgreSQL’s JSONB column type stores, indexes, and queries semi-structured data with the same expressive power that draws teams to MongoDB. The GIN index on a JSONB column makes key lookups fast. Row-level security handles access control that document databases leave to the application layer. For audit logging, temporal tables and trigger-based history tracking give teams a complete record of data changes without spinning up an event-sourcing system or a separate compliance database.
The capability gap here is significant. PostgreSQL ships with full-text search, geospatial indexing through PostGIS, vector similarity search through pgvector, and a foreign data wrapper system that lets it query external sources as if they were local tables. Most teams using PostgreSQL daily are running a fraction of what the engine can do.
The operational consequence of that gap is concrete. Every specialist tool added alongside PostgreSQL introduces a separate failure domain, a separate backup strategy, a separate oncall surface, and a separate learning curve for every engineer who joins. PostgreSQL is already present in the majority of production stacks. Using it more deeply costs almost nothing. Adding Redis, Kafka, or MongoDB on top of it costs a team years of compounding complexity.
What Most Coverage Gets Wrong: This Is Not About PostgreSQL Fandom
When Eduardo Bellani argues that PostgreSQL already solves most problems engineers reach for new tools to handle, the tech press responds predictably: it frames the debate as a loyalty contest. Postgres devotees on one side, specialist-database advocates on the other. That framing is wrong, and getting it wrong matters.
Bellani’s actual argument is epistemological. The problem he identifies is not that engineers choose Redis or Kafka or a time-series database. The problem is that they choose those tools without first asking whether the problem genuinely requires them. That is a question about how engineers think, not about which database deserves their allegiance. Treating it as tribal preference lets the real issue walk out the door unexamined.
The real issue is architectural cargo-culting: the reflex to reach for a packaged solution the moment a problem surfaces, before any first-principles analysis determines whether that solution fits. An application runs slowly, so someone proposes an in-memory key-value cache. An audit trail is needed, so someone proposes an event-sourcing database. PostgreSQL remains in the stack because its reputation is unassailable, but now it sits underneath two or three additional systems that each add operational risk, headcount requirements, and entropy. The complexity compounds without anyone having stopped to ask whether it was necessary.
Most coverage also ignores the organisational incentives that make this reflex persistent. Résumé-driven development is real: engineers who introduce Kafka or Elasticsearch to a stack gain a line item that travels well on a CV. Vendor marketing funds conferences, content, and communities that normalize complexity as sophistication. The social safety of following what large companies do — Netflix uses Cassandra, so we should consider Cassandra — substitutes pattern-matching for reasoning. None of these forces show up in a database comparison chart, but all of them shape database decisions made inside engineering teams every day.
The PostgreSQL discussion, properly understood, is a diagnostic tool for evaluating how engineering decision-making processes actually work. The question it surfaces is not “which database is best?” It is “why do teams consistently choose more complexity than their problems require?” That is a harder question, and it implicates culture, incentives, and professional norms that no amount of Postgres evangelism can fix on its own.
The Real Stakes: Complexity Debt and the Teams That Pay It
Every service added to a production stack carries a hidden invoice. There is the failure surface — a new process that can crash, timeout, or corrupt state. There is the on-call burden — engineers who now need to understand Redis eviction policies or Kafka partition rebalancing in addition to the application logic they were hired to build. And there is the direct cost: licensing, hosting, monitoring, and the senior engineering hours required to keep the whole arrangement running. None of these costs appear in the Jira ticket that proposed the new tool.
The teams that pay the steepest price are small ones. A five-person engineering team that adds a dedicated search service, a separate caching layer, and a message queue has not built a modern architecture — it has built three new jobs nobody officially holds. Operational overhead doesn’t scale down because the company does. A fragmented, multi-tool stack demands the same expertise whether the organization running it has ten engineers or a thousand. Early-stage companies regularly understaff against this reality, then watch their velocity collapse under the weight of infrastructure that was never necessary in the first place.
This is complexity debt. Unlike technical debt — which at least produces working features — complexity debt often produces nothing except maintenance load. Every unnecessary database, every redundant microservice, every tool adopted because a larger company used it represents engineering capacity consumed without a proportional return.
The case for consolidating around PostgreSQL is not a case against ambition or scale. PostgreSQL handles full-text search, time-series data, job queues, JSON documents, geospatial queries, and pub/sub messaging. Teams that use it as their primary data platform eliminate entire categories of operational risk. They retain the engineering attention needed to solve problems that genuinely require new solutions — the ones where no existing tool fits and the decision to build something new is actually justified.
Relational database consolidation is not a constraint. It is a deliberate act of capacity preservation. The organizations that treat infrastructure decisions with that discipline ship faster, page their engineers less, and spend their architectural budget on problems worth solving.
A Better Default: How to Build a First-Principles Habit Into Engineering Culture
The lesson from PostgreSQL’s sprawling feature set isn’t “never adopt new tools.” It’s simpler and harder: exhaust what you already have before you add something new.
That requires a habit, not a policy. The most effective way to build it is to make the question mandatory at the architectural level. Every decision record that proposes a new data store, queue, or caching layer should contain one explicit line: why can’t the existing database handle this? Not a rhetorical gesture — a genuine technical answer with specific constraints named. If the team can’t write that sentence, the proposal doesn’t move forward.
This single forcing function changes the conversation. Engineers stop defaulting to tool sprawl and start actually reading documentation. They discover that PostgreSQL handles full-text search through built-in tsvector indexing, job queues through SKIP LOCKED, time-series workloads through native partitioning, and JSON documents through jsonb. The capability was always there. The reflex to reach past it was the problem.
The cultural shift required is treating simplicity as a mark of engineering maturity rather than a failure of ambition. Right now, the incentive structure runs the other way. Proposing Redis or Kafka reads as sophisticated. Proposing a smarter query against an existing relational database reads as unadventurous. That inversion is costly. Every additional system in a stack increases operational surface area, multiplies failure modes, and demands specialised knowledge that compounds hiring difficulty.
Dan McKinley’s concept of “boring technology” — choosing proven, well-understood tools over novel ones — frames simplicity as a competitive advantage, not a consolation prize. Teams that internalise this ship faster, debug faster, and onboard engineers faster. The org that runs three systems with deep expertise beats the org that runs eight systems with shallow familiarity every time.
Postgres-first thinking, or more broadly the discipline of exhausting existing database capabilities before expanding infrastructure, is not a constraint on good engineering. It is what good engineering looks like when the incentives are set correctly.
