Insights into PostgreSQL: Community, Features, and Future Directions – Interview with Brad Nicholson and Dave Cramer

Tell us about yourself and what you are doing today?

Dave Cramer (Washington, D.C.) lives in a small town in Ontario, Canada, works from home, enjoys racing cars for fun, and currently spends his full‑time on PostgreSQL, fixing bugs in the JDBC driver and adding backend support for features such as search‑path changes.

He also helps maintain the PL/R procedural language and contributes to other interesting technologies, including logical decoding and various reactive/async Java drivers for PostgreSQL.

Brad Nicholson (Toronto) works at IBM Cloud Database as an architect and engineer, focusing on bringing database‑as‑a‑service from internal development to a mature Kubernetes‑native platform and product.

How did you get involved with PostgreSQL?

Dave explains that his path began as a web developer using MySQL before discovering PostgreSQL’s open‑source reliability; after Tom Lane took over the project, he switched, later becoming a post‑doctoral DBA and eventually the JDBC driver maintainer.

Brad recounts moving from a consulting role in 1998, answering questions on the Java mailing list, and gradually becoming a trusted contributor; after the original maintainer left, Bruce Momjian invited him to take over the driver, a role he has held for about 20 years.

What do you see as PostgreSQL’s strengths and weaknesses?

Both agree that the community is the biggest strength—and sometimes a weakness—because it is volunteer‑driven, non‑commercial, and encourages diverse solutions rather than a single vendor‑driven approach.

The community’s openness allows rapid replacement of outdated solutions (e.g., logical replication replacing trigger‑based replication), but the abundance of options can overwhelm users, leading to many “wrong” ways to do things.

Advantages include a permissive open‑source license, strong stability, predictability, security, and extensibility that lets developers build application‑level platforms on top of PostgreSQL.

Weaknesses include limited native sharding, a connection model that does not scale well without pooling, and challenges with logical decoding and logical replication failing over cleanly.

What are you looking forward to in PostgreSQL 12?

Dave highlights the upcoming pluggable table‑storage interface, which will enable columnar storage, encrypted columns, and other domain‑specific storage engines, as well as continued improvements to partitioning.

Brad adds that pluggable storage, combined with extensibility, will turn PostgreSQL into a versatile development platform.

Both mention enhanced JSON‑path support, making JSON handling more developer‑friendly.

Advice for running PostgreSQL on Kubernetes?

Brad bluntly advises “don’t” unless you truly understand why you need it; Kubernetes introduces a new set of operational complexities and mismatches with stateful workloads.

He recommends using established operators (e.g., Crunchy Data, Zalando’s Patroni) rather than starting from scratch, and stresses the importance of understanding the trade‑offs.

Common mistakes when using PostgreSQL?

Both point out the frequent error of not using a connection pool (e.g., PgBouncer), leading to too many client connections and performance problems.

They also note that many teams lack deep PostgreSQL expertise and fail to read documentation or test queries against realistic data sizes.

Any secret performance‑tuning tricks?

Brad says there are no magic tricks; the real gains come from reading query plans, adjusting the data model, fixing bad access patterns, and using extensions like pg_stat_statements.

He emphasizes careful indexing—removing unused indexes—and monitoring I/O, as disk reads/writes dominate performance.

PostgreSQL vs. MySQL: what should application developers consider?

Dave suggests developers must understand transactions and isolation levels; without that foundation, they treat the database as a “dumb” storage layer.

Brad admits he has little to add on MySQL from a developer perspective.

Where do you see PostgreSQL in the next 5‑10 years?

Dave predicts geometric growth as more Fortune 500 companies adopt PostgreSQL, leading to a larger contributor base and more rapid development.

He foresees challenges in scaling community governance as the user base expands.

Brad adds that PostgreSQL’s unique development model may create friction for newcomers accustomed to GitHub‑style workflows, but the project will continue evolving toward a “Swiss‑army‑knife” database handling diverse workloads.

Additional promotional content

For more information, visit the original article at http://jiagoushi.pro/node/1142 and consider joining the “Chief Architect Circle” knowledge community on WeChat, QQ, and other platforms.