Postgres: A Strategic Tool When Deployed Properly

Some companies start using Postgres in a single project, and it grows from there. Others get introduced to Postgres because of an acquisition or because a new off-the-shelf application runs on Postgres. Interesting enough, we observe that most go through several stages of Postgres adoption: Emerging, Expanding, and Strategic. In this article, we explore the practices that helped industry leaders move through these stages quickly, and get as much value out of Postgres as possible without incurring undue risk.
 

How to succeed with Postgres database

We have identified a set of levers that companies can use to accelerate their success with Postgres.

1. Application Tiering
2. Collaboration between DBAs and Development Teams
3. Evangelizing
4. Standardization and Automation
5. Balance of Migration and New Development

Application tiering

Leading IT departments tier their applications, most often in terms of mission criticality and acceptable downtime. Some companies have three tiers: Departmental; Enterprise; Enterprise Mission Critical—other companies have finer grained models that include resilience to different types of failures and disasters, differentiated models for planned outages, regional distribution, etc.

The details of the tiering are less important than the fact that tiering provides guidance for a technology change strategy. While lower tier apps are less critical, they often involve the highest number of total cores, that is, license costs. They also require less database infrastructure for high availability, geo-redundancy, security and other compliance requirements. That makes them worthy targets for a migration to Postgres—without immediately introducing challenges of extreme high availability, geographic redundancy, and other compliance requirements.

Higher-tier apps tend to introduce additional high availability requirements, such as 99.99% or higher availability, encryption requirements, more restrictive security practices, complex operational patterns like flashback, etc. 

Sample application tiering model with RPO (Recovery Point Objective), RTO (Recovery Time Objective) and GRO (Geographic Recovery Objective) targets

Postgres has proven that it can handle very high throughput, low RPO and RTO, and very high availability—but successful organizations start with less demanding applications, and work their way up to higher, more demanding tiers.

Ideally, a strategic migration to Postgres starts with mid-tier or lower-tier applications. These provide ideal proving grounds and allow the team to develop the operational and compliance patterns needed to move to higher tier and enterprise mission critical applications.

Starting with mid-tier or low-tier applications allows the team to master the basics, integrate Postgres with the enterprise management environment for backup, monitoring, security, and authentication. This assures readiness for the next level challenges. Plus, the roadmap will have shown that Postgres successfully reduces cost, is surprisingly easy to adopt, versatile, and developer friendly.

Application tiering will also help identify areas where Postgres may not be the first choice, such as environments that require failover within a few seconds, transparent application failover, write-scalability, or data ingestion rates of multiple terabytes per day.

 

Open source vs. commercial databases

Our experience has shown that the majority of commercial database licenses can easily be replaced by open-source based solutions, and only a small percentage (10% - 20%) take advantage of capabilities that are not readily available in open source. This aligns with Gartner’s prediction that by 2022 over half of the proprietary database applications will have been converted or are in the process of converting to open source and that more than 70% of new in-house applications will be developed on an OSDBMS or OSDBMS-based dbPaaS (State of the Open-Source DBMS Market, 2019).

 

Collaboration between DBAs and development teams

In several customer engagements we have observed a chicken and egg problem: Developers can’t use Postgres because the operations team isn’t ready to support it, or the DBA team says “Postgres is in the solutions catalog, but nobody uses it."

Often, Postgres gets a toe in the door through a project, an acquisition, or because of a new business-driven off-the-shelf app purchase. We call this phase ‘Emerging’. How does the enterprise move quickly to broader adoption and eventual standardization on Postgres?

We have seen successful IT departments drive Postgres adoption by focusing on enabling the DBA team first. That way the CIO creates a safe and reliable platform to roll out Postgres, reduce cost, and enable innovation without putting the business at risk. 

Once the DBA team is ready to support Postgres, how do we convince developers to use it? In many companies, the database infrastructure team and application developers don’t collaborate (that is a polite understatement for some of the relationships we have observed). 


 

How EDB helps customers

EDB has helped many customers with evangelization efforts to help application developers understand the innovation potential, cost savings, and tremendous leverage they can get from a database that can handle GIS, documents, full text search, extensible data types, and much more.

Adoption skyrockets as soon as the application development teams understand how Postgres can help them get to market faster and the operations teams know how to run Postgres reliably and at scale. That’s when Postgres' adoption moves from emerging to expanding and becomes a strategic tool for the enterprise.

We have seen hockey-stick-like adoption curves once the DBA team says ‘Go’ and development teams start understanding the innovation potential and unparalleled speed of development.

 

Evangelizing

Change is difficult and requires that people adopt new technologies and methods, take some risks, get out of their comfort zone, and learn something new. While working with enterprise customers, we have seen that creating a community of practitioners is key to driving change. We have organized pizza lunch-and-learns, local meet-ups, database days, bootcamps, and summer schools to help our customers create this grass-roots effect.

Postgres, as an open source project, is extremely well positioned to drive this kind of learning. That is how the open source community moves forward at blazing speed—there is no reason that effect cannot be replicated in the enterprise.

Traditionally, a Center of Excellence would be the nexus for such a technology change. In the age of open source, we have seen that an open source community-inspired approach works faster and is more aligned with today’s developer. A community of practitioners, pulling from the DBA community and from the application development team, can break down the traditional walls between development and DBA team. This kind of change is needed to create a DevOps motion where application development, database development, and database operations work hand in glove.

 

Automation and standardization

One-off database implementations, where every database configuration is different, are hugely expensive to manage. They make it very hard to achieve predictable performance and high availability. At the same time, one-off manual implementations take way too long. It is no longer acceptable to take 4–6 weeks to provision a database. In the age of the cloud, that should take 15 minutes, including updating the configuration management system and the cost accounting system.

Faster provisioning can only be achieved through automated deployment tools such as Terraform, Ansible, Chef, or Kubernetes. The application tiering discussed above is crucial to a successful automation approach, so that templates for different tiers and sizes of databases can be created. 

Creating a fully automated, self-service deployment structure for Postgres helps reduce barriers, helps projects try Postgres out, encourages innovation, and just gets stuff done faster.

Companies that continue relying on manual database deployment are not likely to succeed with Postgres or any other technology infrastructure innovation. The application development team will see the database infrastructure team as a hindrance rather than a partner. A true DevOps motion requires automation to keep up with agility requirements.

 

Balance of migration and new development

Postgres’ low cost and compatibility with Oracle (when using EDB Postgres Advanced Server) are extremely attractive for IT leaders and application owners. Innovation, ease of use, universal availability, good documentation, and a global knowledge base attract developers and architects.
Migrations tend to focus on re-platforming, ‘lift-and-shift’ with minimal change. While such projects  can greatly reduce the cost of ownership, they can be difficult to complete as they involve all aspects of legacy data management: the data, the code, the application interface, and operational ownership, such as security, disaster recovery, and other compliance challenges.

Innovation projects that leverage PostGIS, Foreign Data Wrappers, and innovative Postgres extensions, tend to be focused on driving additional value-add and customer intimacy. While cost reductions are important and absolutely feasible with Postgres, our experience has shown that customers realize great value when they use Postgres to develop new capabilities. For example, they create geo-location aware mobile apps using PostGIS, highly personalized applications using JSONB, and powerful search tools that combine database searches with Postgres full text searches.

Some IT departments combine the best of all worlds in a strategic approach. First, they move from Oracle to Postgres, then they move to a cloud model (private or public), and then they drive innovation by making the application geo-aware with PostGIS, highly personalized with JSONB, integrate with Foreign Data Wrappers, and deploy with containers and microservices. As part of that transition, they start designing for Postgres and take full advantage of Postgres’ native innovation capabilities.

The Postgres adoption journey

Postgres’ phenomenal success puts pressure on IT departments to move rapidly through the stages of emerging, expanding, and towards strategic adoption. Developing a maturity model becomes key. This model encompasses application tiering, the motion to DevOps, development of an internal knowledge base, a community of practitioners, and automation tools—all with the goal of migrating away from expensive and inflexible legacy databases towards platforms of greater innovation. 

Our experience has shown that companies that make this an intentional, planned, and strategic journey make the fastest progress towards measurable results. EDB has the resources and the experience to help design tiering models, enable the fundamental collaboration needed for DevOps, create automation solutions, bring powerful Postgres evangelists to the table, and be a partner on the Postgres journey.

Use Postgres — Get Stuff Done!