Last month I got a chance to meet and interview Bruce Momjian, a core member of PostgreSQL community and Senior Database Architect at EnterpriseDB. He was in Singapore for pgDay Asia 2016 and FOSSASIA 2016. I got a chance to spend a good amount of time with him and discuss various aspects of Postgres development and adoption. He was quite excited to be in South East Asia for the first time and appreciative of efforts by Ashnik for “getting Postgres started in the region”.
He re-counted how he started exploring Postgres and building community around PostgreSQL. Like any DBA and developer working with databases, he was curious about internals and optimizer of databases. As he asserts “Postgres being open source provided him a great opportunity to look inside and explore”. Back then “the project had really good potential”, but it needed some structure and team around it. Today the community has grown and as per him, the key reasons for the success has been ability to retain developers and discipline.
It is nice to learn how he constantly keeps looking at new geographies and tries his best to expand Postgres adoption in new regions and hire developers to “volunteer” for community development. He admits that “it is not easy to get started with contributing to Postgres community as a coder”. This is mainly because of the “high quality standards maintained for the Postgres code-base”. But there are many ways for one to get started e.g. like by joining IRC or mailing lists, answering queries, helping improve documentation and making test-case more robust.
He joined EnterpriseDB in 2006, mainly because of “the approach which EnterpriseDB had to add tooling around the PostgreSQL”. He balances his role at EnterpriseDB and community very well. At EnterpriseDB he helps steer the roadmap and features of upcoming releases and tools, provides help to developers who come on-board from other databases and help technical and marketing teams. For him “how Postgres community can help a user and how EnterpriseDB can help a customer” is more or less the same. He referred to Ed Bojiyan’s interview where Ed had emphasized on health of Postgres community being very important to EDB’s success.
On being asked about some of the recent contributions of EnterpriseDB to PostgreSQL code-base, he spoke about two major feature-sets being led by Robert Haas – Parallelism and Sharding. Parallelism in v9.6 will let Postgres take advantage of multiple I/O channels and CPUs for the same query. It will help in “making Postgres as a good fit for data-warehouse and Big Data”. Native sharding in Postgres is a feature which is being pursued with help of foreign data wrappers. While we were discussing the course of development which Parallelism has taken in Postgres and which will be taken by Sharding, we discussed how Postgres community tries to break large changes in small sets. He was in an agreement to my observation that “Streaming replication too went through a similar cycle”. He mentioned that “community works differently from proprietary vendors, who would dump a whole lot of changes in a new version which comes after 5 years”. Community would work “on a year-on-year release cycle” and “add features in stages”. This also helps in “adding features quickly and getting feedback from users”. Apart from Streaming Replication, he added that pg_upgrade and Windows port of PostgreSQL were also done in the similar way.
PostgreSQL has been a choice for those who want to cut down cost, but that scenario has changed with recent features and developments. Customers are now opting for PostgreSQL because of advanced features, industry innovations, stability and quality of code. He mentioned how Postgres has been a leader in “adding JSON data-type, block range indexes, foreign data wrapper and optimizing for large servers”. The key strength of Postgres development has seen many eyes watching and reviewing the code, quick feedback from users and close relationship between people who are developing Postgres and those who are using it. Many of the features in Postgres have been implemented with extensibility and Foreign Data Wrapper (FDW) is just one of them. It is not just a feature but a whole infrastructure for everyone to implement their own Data Wrappers for Foreign Data Servers of their choice. With new advanced features like filter push-down, join-pushdown and aggregation pushdown, FDW is also going to be the core of sharding in Postgres. So it actually becomes a “double-win situation” for Postgres community. Our team had developed a solution using FDW for a customer using MongoDB and Postgres. The FDW in fact is so powerful that MongoDB used PostgreSQL and FDW as a connector for reporting tools.
During his talk at pgDay Asia he mentioned that initially Postgres community was working towards standard compliance and adding stability. But in the last few years the community has added more enterprise grade features. He took a peak into the future of PostgreSQL and some of the upcoming features. It was great having him here in Singapore and take a few learnings from his experience with Postgres. I look forward to seeing him again at pgConf US, NYC. I will be participating in the Regulated Summit as a moderator of one of the panel discussions. With my knowledge of other relational databases and NoSQL DBMS, I will be helping organizers to shape the panel discussions and steer them in a direction relevant to enterprise users. In my next article perhaps I shall share my experience of meeting different users and developers from Postgres community at pgConf US.