During architecture diagram reviews, boxes sometimes appear whose origins no one can explain: "A predecessor added it," or "I think it was meant to prevent connection spikes." Because it is running, it gets left alone, quietly continuing to appear on the monthly invoice.
The troublesome part about this state is that no one takes the step to remove it. Because nobody knows whether it is actually effective, there is no way to justify removing it if an outage occurs afterward. As a result, components that might not be working remain in place, under the ongoing assumption that they are effective.
A real-world case published in August 2026 clearly illustrated this dynamic.
When the issue wasn't the configuration, but the specification
The development team at Dress Code published a report detailing how they introduced RDS Proxy to Aurora PostgreSQL for their application, operated it for several months, and ultimately removed it. They cited the following points as the rationale for removal:
SQL text exceeding 16 KB generated by Prisma triggers RDS Proxy session pinning. This is a hard limit common across all AWS-supported engines and cannot be bypassed via configuration. At the company, pinning occurred in about 20% of all client sessions, rendering connection multiplexing virtually useless. All that remained were costs of several hundred dollars a month and the failure surface inherent to the proxy layer.
AWS documentation also explicitly states that statements with text sizes exceeding 16 KB will cause the proxy to pin the session. Because pinned connections cannot be shared with other sessions, the benefits of multiplexing are lost to that extent.
The key point here is that this was not a matter of inadequate tuning. If it were a performance issue that could be mitigated through settings, keeping it after adjustments would be an option. However, when dealing with a specification-level limit and the SQL is generated by an ORM rather than in-house code, there is also limited room to shorten it from the application side. SQL generated by ORMs easily becomes verbose for queries that include relations.
A single metric reveals whether it's working
What makes this case practically useful is that the metric used for evaluation is concrete.
RDS Proxy provides the DatabaseConnectionsCurrentlySessionPinned metric, which indicates the number of pinned connections every 60 seconds. Comparing this metric with the total number of connections through the proxy reveals with actual numbers whether multiplexing is working.
In other words, for this component, a state of "not knowing whether it's working" shouldn't fundamentally exist. People simply aren't looking.
The same applies to other components: cache hit rates for caching layers, delivery ratios for CDNs, and queue wait times for queues. Even though metrics to gauge effectiveness can be defined for most things added "just in case," they are rarely established at the time of introduction.
The reason this isn't determined is understandable. At adoption time, the focus is on "will it work once added?" rather than "was it worth adding?" Once operational, teams move on to the next task, and measurement becomes nobody's job.
Why removal becomes impossible
Another key topic is the decision-making around removal.
Even when an element is found to be ineffective, removal does not proceed quickly. The reason lies in budgeting rather than technology. Additions carry the justification of being "safeguards," but removals rarely have a compelling label. Saving a few hundred dollars a month often looks minor compared to the labor required for removal, keeping its priority low.
Furthermore, removal comes with a distinct perception of risk. When introducing something, "it might be risky without it" passes easily, but when removing it, the question becomes, "Who will guarantee that removing it is safe?" It is asymmetric.
We believe there is only one way to break this asymmetry: write down the conditions for removal at the time of adoption. Discussing "whether it's okay to remove" post-launch always leads to contention, but if you decide upon introduction that "it will be removed if this metric falls below this value," execution becomes mere administrative procedure.
Note that in this case study, a replacement was also prepared following removal. Because Prisma 7 returned control over connection behavior to the application side, protections against spikes were reportedly replaced with pg.Pool configurations. The removal succeeded in part because an alternative existed. When defining conditions for removal, you must pair them with what will substitute for it afterward, or the conditions will remain an empty gesture.
What to document at the time of adoption
Whether you are the client ordering the work or the contractor delivering it, the points to agree upon when adding a component are identical.
State the purpose of the addition with concrete numbers. Not "preventing connection exhaustion," but "ensuring concurrent connections do not exceed a certain percentage of the database limit." If the objective isn't quantifiable, you cannot judge its achievement.
Document the metrics to measure effectiveness and how to verify them. Include the specific metric names. If adding them to a dashboard is part of the adoption work, you eliminate the hassle of searching for them later.
Specify the timing for evaluation. Set concrete dates, such as one month or three months after introduction. Measurements without deadlines never get carried out.
Outline how to handle cases where no effect is observed. Remove it, re-evaluate after changing settings, or retain it while re-approving the cost. Any option is fine, but making the decision beforehand is what truly matters.
Rather than writing these into detailed specifications, leaving three to four lines in configuration change tickets or meeting minutes is sufficient. The turning point is not the volume, but whether it is written down at all.
Architectural decisions regarding databases themselves are covered in When to Use Aurora Serverless. Additionally, how to write numeric acceptance criteria for performance issues directly connects to our piece on Using Query Counts as Acceptance Criteria.
What to do next
Open your company's infrastructure architecture diagram and identify the components added over the past year. Then count what percentage of them have numbers available right now to demonstrate their effectiveness.
For those without figures, a realistic start is simply picking one metric and placing it on a dashboard. Deciding whether to remove it can wait until afterward. If you debate removal without measuring, the outcome will invariably be keeping it "just in case."
GleamHub accepts inquiries regarding infrastructure audits, identifying cost-reduction opportunities, and reviewing existing system architectures through our Development, AI, and Automation Consultation. Because our approach varies depending on configuration scale and operational status, we provide individual estimates. Please reach out via Contact Us.
