The Future of Postgres in a Multi-Cloud World: A Developer Perspective

The annual PGConf India conference just took place in Bengaluru on February 26-28, where EDB had seven of its experts speaking—including a keynote address by senior VP of product development, Marc Linster titled, "The future of Postgres in a multi-cloud world."

Marc talked about Postgres as the undisputed leader of relational databases for new and modern applications. His keynote looked at how customers take advantage of Postgres as their universal data platform given its ability to run in containers, on every cloud computing platform, in every data center and on every developer laptop.

In this post, we’ll expand and this topic, from a developer’s perspective, to provide more insight on the increasing importance of Postgres as multi-cloud advances.
 

Best Practices for Developer Decision Making

In an agile world, developers drive decisions! While IT architects, CIOs and CTOs still play a major role in setting up the list of allowed software packages, increasingly application-specific decisions are made by developers. 

How do developers choose a database or persistence API? The first and most important criteria are the core capabilities, such as transactions, flexible data type (JSONB etc.), full-text search, and geographic information systems. Innovation, meaning how quickly do new features become available and how aligned is the product roadmap with the developer’s perspective, tends to be the second criterion. Nobody wants their app to turn into a zombie just because they chose a data platform that is stagnant.

Performance is another key aspect. Platform lock-in matters a whole lot, especially in agile projects where not everything, including which cloud infrastructure will be used, can be known at the project’s inception. Vendor lock-in and manageability are very important too, even if they tend to be more important to the IT team than the developer.

The fear of vendor and platform lock-in, and the desire to not commit to a data platform that might be stagnant, too expensive or just simply not available on the target infrastructure, leads the developer to abstract away from specific database capabilities such as stored procedures, data types, or advanced operators. The developer limits herself to standard ANSI SQL and Object Relational Brokers, and recreates a lot of database capabilities in the application logic, including transactional consistency, data management, queries, etc. This can lead to large amounts of custom code, significantly lower performance, and transactional inconsistencies. Dimitri Fontaine explores these problems in detail in Chapter 3 of his excellent book “The Art of PostgreSQL.”

Why Postgres Solves Developer Concerns

What has changed? Postgres has overcome many of these concerns. Postgres is available everywhere - on all key public clouds, on all relevant operating systems, and on all virtualization platforms that matter to modern development. On all these platforms, multiple vendors provide support and users can choose to self-support. Choosing Postgres assures the developer that there will not be any platform or vendor lock-in.

Figure 1: Postgres is available everywhere and avoids vendor lock in.
 

Postgres Advancements for the Future

At the same time, Postgres has become almost 50% faster over the last 4 years and management tools, such as EDB’s Postgres Enterprise Manager and EDB’s Failover Manager make it easy to run highly available Postgres infrastructures at scale in the Enterprise.

Postgres has undoubtedly become the most innovative and dynamic data management platform. Gartner has recognized this by featuring EDB Postgres in their Magic Quadrant for Operational Databases for seven years in a row. Bruce Momjian, in ‘Will Postgres Live Forever’, describes why this has happened.

So what does this mean for the developer? Now that Postgres avoids lock in, is performant and scalable, provides multiple data models, text search and much more, the developer can dive deeper into the Postgres capabilities than just the ANSI SQL interface. They can take advantage of functions, stored procedures, a rich library of data types, extensions such as PostGIS and rebalance the business logic across stored procedures and custom application code. All of that, without fear of lock in, obsolescence, or performance issues!

This will allow them to write less code, have a much more performant application, and go to market faster. But, she needs to stay away from cloud-vendor specific features to avoid infrastructure lock-in

Use Postgres - Get Stuff Done!

Keep up on where EDB will be next by visiting our Events calendar!