Open source databases continue to gain traction due to various reasons – be it diverse innovation, influence democratization, or cost management. Marc Linster, CTO at DB Serv, emphasizes these models in his webinar, “5 Tenets for 2022 Database Planning”.
Having been around for almost a quarter-century, postgresql support is seen as reliable. However, opting for it doesn’t mean you’re exempt from certain responsibilities. Some may be evident, but others can be realized through unfortunate experiences. Take, for instance, a case that DB Serv support once encountered.
Case Study: PostgreSQL Support
A long-term customer reported intermittent issues with their production setup. Despite being associated with DB Serv for months, they had never liaised with our support team before.
The issues varied: sometimes application performance would dip, with no discernible pattern. This could last minutes or hours, with no relation to user numbers or time.
Usual diagnostic procedures like Postgres monitoring, database log file checks, and configuration evaluations revealed no potential causes. Even version information was initially absent, and we had to instruct them on its retrieval.
When delving deeper, it’s essential to question whether the database is the real problem or if it’s symptomatic of broader environmental issues. This client monitored their system with SolarWinds, which mostly showed normal performance:
- Network usage hovered around 35%, peaking at 85%.
- Other hosts operated as expected.
- Application hosts functioned well, with memory usage under 25% and storage around 53%.
But there were inconsistencies:
- Issues arose only when applications connected with Postgres databases.
- During downtimes, database-hosted CPU loads neared 53%, and memory usage skyrocketed to 100%.
The client used an older 9.4 version, and potential memory issues associated with its early releases hadn’t been ruled out.
How was their system set up? The usual ‘postgres -V’ command failure often hints at installation issues. Here, the problem was the client’s choice to compile PostgreSQL independently, bypassing standard installation methods. This meant a patchwork system without any clear reliability references.
The remedy? We guided them to re-install using standard Postgres repositories, which also facilitated smoother upgrades. Once reestablished, the problem disappeared. A few culprits were identified, but the main takeaway was the importance of maintaining database integrity.
Why PostgreSQL Support Matters
While many organizations efficiently operate Postgres autonomously, others rely on vendors to ensure optimal functionality. It’s about aligning with objectives. Some prefer the expertise of dedicated PostgreSQL vendors so that internal teams can concentrate on product and customer objectives.
A trustworthy vendor should:
- Enable efficient and reliable implementations.
- Guarantee software safety and enterprise-strength.
- Provide consistent support, both for issues and queries.
The above-mentioned case is an illustration of when things go awry. The client ventured into self-compilation without adequate knowledge, compromising their system’s stability and performance. Yet, with just one interaction with our support team, they transitioned to a secure deployment.
While DB Serv prides itself on its robust technical support, it’s vital to acknowledge that choosing a vendor is fundamental when embarking on a PostgreSQL journey. It’s not just about issue resolution but also about proactive guidance, ensuring seamless operations.