How RadixTrie helped a client decommission unused Postgres databases

RadixTrie was asked to help a client identify unused Postgres databases and hosts. After a sharp increase in virtualisation costs, these unused databases were creating unnecessary spend across CPU, storage and memory. By identifying what was not being used and taking on the decommissioning process, RadixTrie helped the client remove waste and reduce cost in a controlled way.

Unused databases still use resources. They take up storage. They use memory. They consume CPU. They add backup and access management work. When the estate is large, this adds up quickly. Even if a database is not actively used, it can still carry cost across the environment.

The client had a large Postgres environment with a defined structure for hosts. The expected setup included one primary, two replicas and two high availability proxy hosts. RadixTrie was asked to identify databases, hosts and instances that showed little to no activity over a certain period. In some cases, hosts also had multiple instances or were not being used according to the correct structure. By finding these unused or incorrectly used hosts, the client could reduce cost through multiple channels, including CPU, storage and memory.

The work was not only about finding unused databases. The decommissioning also had to be done properly. The process required change tickets, approvals from different team members, affected configuration items, backup retirement and privileged access updates. At the start of the project, RadixTrie identified the hosts and instances that needed to be decommissioned and the people needed to start the process. To speed things up, RadixTrie decided to take on the decomms directly instead of only identifying the unused hosts.

RadixTrie followed a clear eight day decommissioning process: 1. Verify the hosts to be decommissioned 2. Log a change to decommission the identified hosts and capture all affected configuration items 3. Set the change duration to eight days to allow for stopping the cluster and completing the decommissioning 4. Stop the cluster for seven days using the API, giving teams time to flag if the host was still needed 5. Execute the decommissioning procedure through the API on the eighth day 6. Support the deployment and confirm that the host was successfully decommissioned and updated in the service management system 7. Work with the backup team to retire the related backups 8. Add a task for privileged access support to remove the hosts from the password safe After this, RadixTrie updated the team, updated the change ticket and made sure the other teams completed their tasks.

Once the decommissioning was completed, the client could immediately start seeing savings across: • Storage • Memory • CPU • Backups • Operational overhead The work also helped clean up the Postgres estate. There were fewer unused hosts to monitor, support, back up and manage. The result was a more efficient environment with less waste and better control.

Cost reduction does not always need a major migration or new platform. Sometimes the value comes from identifying what is already in the environment, checking what is no longer needed, and removing it safely. For this client, RadixTrie helped turn unused Postgres databases and hosts into direct resource savings. Less waste. Less complexity. Better use of the estate.

Related reading: PostgreSQL Support in South Africa: Running Postgres in Production Without the Guesswork · The Database Health Check: What a Good One Covers and What It Finds · Managed DBA Services Explained: What You Hand Over, What You Keep