This blog post lists tools for managing Postgres in the enterprise. While this is a big topic, there are common denominators that we have seen in many Postgres projects.
Our list is not exhaustive, but it provides a starting point.
Tools
We list tools for Development and Administration, Performance Tuning and Monitoring, High Availability and Disaster Recovery, Connection Pooling and Query Routing, and Migration.
Not all the tools listed below are part of the EDB support scope. Many of them are open source tools with varying degrees of support and maintenance. (**) identifies tools that are part of EDB’s support scope.
Development and Administration
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Performance Tuning and Monitoring
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Disaster Recovery and High Availability
|
|
|
|
| EDB Postgres Distributed (**) | Achieve up to five 9s of Postgres extreme high availability—whether on-premises, in the cloud or in a hybrid architecture. https://www.enterprisedb.com/docs/pgd/latest/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Connection Management/Connection Pooling
|
|
|
|
|
|
|
|
|
|
|
|
Migration from Commercial Databases
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
One of the most important lessons learned is: “Don’t go it alone!” Postgres is mature, and in many regards, it behaves like Oracle and SQL Server, but there are significant differences in tooling, management practices, and performance behavior.
The ROI of Postgres projects is very high. Project delays, partial implementations, and substandard performance are the enemies of a timely move to production.
Supported Postgres
We highly suggest that users work with a well-established Postgres company that has a staffed 24X7 support team with commercial-grade support SLAs. That support team must be backed by software engineers who are involved in the development of the Postgres database (check the list of committers and contributors at PostgreSQL.org -- don’t work with ‘Postgres Companies’ that don’t have several full-time team members who are on that list. They will not be able to help you in a timely manner on the rare occasion where Postgres has issues).
EnterpriseDB’s Postgres Advanced Server is a managed fork of Postgres. This allows EnterpriseDB to provide features for customers (Oracle compatibility, Resource Management, Query Hints, PCI-compliant password management, etc.) that may otherwise not be possible in the community process.
Technical Account Management
Technical Account Managers (TAMs) are a staple of the commercial software world, especially for mission-critical infrastructure software. TAMs provide an intimate and knowledgeable link between the customer’s needs and the software provider’s engineering team. TAMs greatly improve communication and help make projects successful. They also act like the customer’s advocate and influence the product roadmap.
DBA Services
Specialized Postgres DBAs monitor and manage Postgres databases in the customer’s data center, in cloud IaaS deployments, or in cloud-based DBaaS projects. Postgres is close to Oracle and SQL Server, but some key management processes, such as bloat and vacuum, or backup/HA, are different. Query tuning and performance management practices also differ significantly - especially when considering the requirements of Tier 1 99.99%+ SLA solutions.
Many customers use DBA services as ‘training wheels’ for their first project; other customers focus their in-house DBAs on innovation and data management and use EDB’s DBAs to keep the lights on.
Consulting and Architecture Advice
Highly performing and reliable Postgres architectures are foundational building blocks if an enterprise wants to transition a significant part of their database estate from commercial databases to open source based ones. Understanding how to use Postgres and how to take advantage of its unparalleled innovations, its flexible data model, extensions, GIS and document capabilities, is important in order to achieve the ROI and get value from Open Source.
The Need for an Integrated Platform
The open-source community has provided a plethora of tools and capabilities around Postgres - almost everything from HA to DR and log analyzers, are available as ‘free’ building blocks. However, none of the blocks fit together seamlessly, none of them are on the same release schedule, and they are not covered by the same support SLA. None of that matters if an enterprise can invest enough into a large number of in-house Postgres knowledgeable resources, has plenty of time to mature its Postgres projects, and does not plan to use Postgres for Tier 1 mission-critical applications.
However, that is not acceptable for enterprises that want to take advantage of open source-based technology to reduce cost, drive innovation, and support digital transformation. Those users require:
- An integrated platform that includes management, monitoring, tuning, HA, and DR tools that fit together seamlessly and create a robust management platform
- One integrated release schedule to make sure that the tools work together
- An integrated SLA and support structure for the tools and the database. A whole is only as strong as its weakest part.
Conclusions
The enterprise demands imposed on an open-source based platform, such as Postgres, are in no way different from the demands imposed on closed source software. Increasing use of Postgres for mission critical apps means that the tooling and the best practices align increasingly with traditional soft practices. Integrated platforms, single vendor support solutions, and the need for an agile roadmap are obvious requirements when enterprises start betting on Postgres.
Use Postgres - Get Stuff Done!