Few things have been more surprising than the resurgent popularity of PostgreSQL. For years, PostgreSQL lived in the shadow of its younger, sexier MySQL cousin. But through a series of missteps by Oracle, MySQL's new guardian, and a range of product improvements, PostgreSQL is hip again. In fact, it's now the fourth most popular database, according to DB-Engines.
To get a sense for how and why PostgreSQL has seen such a profound resurgence in the past few years, I talked with Bruce Momjian, core member of the PostgreSQL open-source project and Senior Database Architect at EnterpriseDB, one of the primary commercial backers of PostgreSQL.
TechRepublic: What is your role at EnterpriseDB and in the community? How does that balance out?
Momjian: I have worked for EnterpriseDB for eight years. In the early years, I played a role in helping shape the direction of EDB's software and contributed to developing strategy. Now that EDB has grown and the team includes a deep bench of PostgreSQL experts, I spend more time helping with training and working with large enterprise customers to help them understand how Postgres can address their specific demands.
During this time, my role in the PostgreSQL development community has largely been unchanged. EDB supports my work in the community as one of the ways the company contributes back to the Postgres project. I help organize the project team, contribute to overall decision-making, and recruit new members for core activities. I also present at many conferences to help foster greater awareness and educate Postgres users where I can.
TechRepublic: PostgreSQL has been around for decades but seems to be enjoying a Renaissance. What do you think is driving the interest and demand?
Momjian: We are experiencing a perfect storm of goodness. On the one hand, confusion and uncertainty around MySQL as well as other issues with the technology is helping us — and on the other hand, Oracle's high costs and aggressiveness toward its customers is helping us with many users. Then there is increased budget pressure due to the bad economy.
Advances in Postgres have also drawn the spotlight. Recent releases have introduced streaming and cascading replication, expanded foreign table support, unlogged tables for performance gains, increased CPU scalability, and index-only scans.
And perhaps the most important is how Postgres has advanced on NoSQL technology with our work with JSON. It's possible now to use Postgres for achieving the same results as you would with some NoSQL solutions, and we're continuing to move forward. NoSQL on ACID is a compelling story that we're now starting to tell. With all that, Postgres is finally getting the recognition it deserves.
TechRepublic: If I'm choosing between PostgreSQL and MySQL, what should push me to choose PostgreSQL? How about vs. Oracle or SQL Server?
Momjian: There doesn't seem to be any reason to choose MySQL, unless you need to use some application that works only with MySQL — this has been true for many years but is only now being recognized. Data and durability has become more important for many companies that started out using MySQL, because it was easy to get up and running quickly. During the internet boom, for example, people thought it was good enough for what their online applications needed to do, but that's not the case anymore, as more companies seek higher standards of durability and performance and now turn to Postgres.
With each new release of Postgres, there are fewer technology-driven reasons to choose Oracle. For a long time, Postgres lagged Oracle in enterprise-class features. The community spent many years laying the foundations for enterprise-grade features and capabilities and then building them out. Now, Postgres delivers almost everything enterprises need. And Postgres' ease of use and reduced costs are certainly big draws for Oracle users. The story is similar for SQL Server.
TechRepublic: There are no "tech household" names in the PostgreSQL community, yet some of you — yourself included — have been actively involved, spinning the project spun out of Berkeley. Why have you, personally, and PostgreSQL as a group stayed out of the broader open-source and database discussions?
Momjian: Workhorse relational databases were considered "old folks" technology for a long time: you had the SQL standards, and software development followed the standards. The requirements inherent in enterprise-relational databases, like reliability and stability, also helped discourage experimentation. This made enterprise-relational database development seem "boring" and kept folks from being curious about what we were doing. People were more interested in the expansion of Linux and sexy, new internet technologies.
During that time, the community was getting organized and starting work on strengthening our technology. Meanwhile, at EDB during that time, we amassed more than 2,500 customers and built a powerful recurring revenue business with 17 consecutive quarters of growth.
Now that Postgres has mostly implemented the SQL standard and most of the features that enterprises need for mission critical workloads, we can start working on more cutting-edge stuff, like JSONB and advanced indexing. This "sexier" technology is coming at a time when more and more companies are adopting Postgres. That goes back to the perfect storm and is helping increase our profile.
TechRepublic: There seems to be an ongoing debate about the ability of NoSQL technologies to better meet today's data demands. What do you make of the discussion? Any repeats of the past? Any mistakes or lessons from the past? And where does PostgreSQL fit in the discussion?
Momjian: There are several facets to that discussion: 1) clustering and data sharding; 2) extremely flexible data model that supports incremental development and eliminates lengthy discussions between developers and DBAs; 3) easy integration with Web 2.0-focused programming languages that abstract away the SQL language details.
While clustering and sharding may play a role in some decisions, speed to market, time to value, and ease of development tend to be much more important.
With JSON and JSONB, Postgres provides great data model flexibility and allows developers to migrate data between semi-structured (JSON) and highly structured (ANSI SQL). Experience has shown that clear structures emerge as an application design matures, and developers can take advantage of a broader range of capabilities in Postgres than in most NoSQL-only databases. An increasing number of development language communities recognize that Postgres plays a growing role in this space and are starting to provide better support for the developer who does not want to become a Postgres expert.
As for lessons from the past, history shows that relational systems usually adjust to new technologies and give people the best of both worlds. Postgres implemented key/value stores in 2006 so that it's possible to build schema-less key/value stores but with ACID compliance in Postgres. This came about long before the capability had even achieved the level of visibility it has now. The same is already under way with other NoSQL technologies, as Postgres' advances with JSON illustrate. We're able to build these capabilities into Postgres, but the advantage is that with Postgres, these NoSQL capabilities have the benefit of ACID compliance and relational capabilities as well.
Postgres provides application teams the best of NoSQL and SQL in the form of 'Not only SQL'
TechRepublic: How do organizations determine when they need a specialized database technology? Do you promote the idea that PostgreSQL is suited for every organization and every need? How does PostgreSQL stack up against other relational databases?
Momjian: Postgres can support 80% of the workloads in today's enterprise at a lower cost than traditional databases and with greater performance and durability than MySQL. But even though it may not support every application in the enterprise, Postgres has the capacity to be the hub in the data infrastructure. Postgres has foreign data wrappers that allow it to access data in many other data stores, like MongoDB, Oracle, and even Twitter. If you already have data in those data stores, you can use Postgres for what it is best at. These were developed by the community as new demands emerged.
In addition, the object-relational features of Postgres we inherited from Berkeley have helped us to further expand Postgres with extensions like PostGIS, which enables Postgres to handle specialized, geospatial workloads. This ability to expand the database will continue to be one of our strengths, as well as easy administration, a powerful development environment, flexibility, reliability, and of course, low cost.
TechRepublic: What is the roadmap for PostgreSQL in 2014 and 2015?
Momjian: Well, our binary JSON (JSONB) to be released later this year will be a game changer for developers, because it allows rapid JSON access and very flexible JSON indexing that beats the other database offerings. That is an important part of the PostgreSQL 9.4 release coming this fall.
For 2015, we are focused on parallel query capabilities for better resource utilization by complex queries, built-in logical replication to allow more fine-grained replication control, and horizontal scalability for when you need easy multi-server scaling.
Are there other questions that you'd like to see answered about PostgreSQL? Let us know in the discussion thread below.
Matt is currently head of the developer ecosystem at Adobe. The views expressed are his own, not those of his employer.
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.