Reading time: 12 minutes
PostgreSQL is the World’s most advanced Open Source Relational Database. The interview series “PostgreSQL Person of the Week” presents the people who make the project what it is today. Read all interviews here.
Please tell us about yourself, and where you are from.
I guess the best way to answer this is to say I am from the US. I moved around a lot as a kid – California, Michigan, Utah, Washington State. In 2010, I moved abroad, and have not moved back. Since then I have lived in Indonesia, Sweden, and Germany. I am now living in Indonesia again.
How do you spend your free time? What are your hobbies?
My hobbies include photography, cooking, and traveling. I enjoy exploring new cuisines. My favorite cuisines right now are Padang Cuisine from West Sumatra, Lithuanian cuisine, and Italian but this changes periodically. I expect to explore Javanese and Balinese cuisine more in the near future, and to learn more German dishes as well.
Any Social Media channels of yours we should be aware of?
On LinkedIn I am often happy to connect with anyone involved with PostgreSQL.
I have a Facebook page for my photography.
And of course my Youtube cooking channel: World Traveler Cooking.
Last book you read? Or a book you want to recommend to readers?
I recently read the 1985 edition of Augustine’s Laws, by Norman Augustine. The book is a humorous and darkly accurate look at business, US government contracting, project management, aerospace, and technology. It is still very much relevant in our industry, or even in all industries. It is a book that uses math in ways that will have you laughing, crying, and saying “we’re doomed” all at the same time. You can find it on Archive.org.
When did you start using PostgreSQL, and why? How has your involvement with PostgreSQL evolved since then?
In 1999, I was trying to modernize my programming knowledge, and so I figured I would teach myself how to write PHP code. As my job involved triaging tech support calls, I figured a great project would be a tech support case tracking application. I evaluated PostgreSQL and MySQL.
At the time, PostgreSQL supported transactions while MySQL did not, so I eventually used it as my primary database system.
More significant in this regard was the founding of the LedgerSMB project in 2007 with a number of other people in the PostgreSQL community. We decided early on to support PostgreSQL only and move a lot of the logic into user defined functions. This project is still going strong and it marks the beginning of the PostgreSQL focus of my career. After that, I began to blog about how LedgerSMB uses PostgreSQL, though I haven’t blogged there for a while.
In 2015, I moved to Sweden and began working on a project involving a massive life sciences database for Novozymes in Denmark. This was my first experience with multi-TB databases, and it was a specialty field with large domain-specific requirements. I learned a massive amount on that project in terms of working with PostgreSQL at scale. Since then I have been involved in PostgreSQL in distributed environments, as well as helping companies with community relations.
Do you remember which version of PostgreSQL you started with?
It was 6.5. PostgreSQL was quite a challenge to use at that time. We only got WAL logging and crash recovery in 7.0 and the ability to drop columns from tables in 7.1. Foreign key constraints, roles (replacing users and groups) and many things we take for granted today only came later. It has been quite interesting to watch the development of this database system over the last 23 years, and every year we get new and useful features.
Have you studied at a university? If yes, was it related to computers? Did your study help you with your current job?
I studied liberal arts at The Evergreen State College in Olympia, Washington. In my college and university days, I took precisely two courses relating to computers, one devoted to Fortran, and one to building models of environmental systems. Most of my classes were about history, however.
I actually wanted to go into technical corners of the humanities, such as historical linguistics. For better or worse, this never happened, and I ended up in this industry instead. This being said, history and computing have a very rich and complex relationship and I get a lot of mileage out of Henry Spencer’s statement that “those who do not understand UNIX are destined to reinvent it badly.” I think that statement is applicable to computing and historical discussions alike and adds something that the more famous quote it was based on lacks.
The thing about being on a software or database engineering team with a formal education in history and the humanities, is that it leads me to a different perspective than those who studied computer science. I tend to be more aware of software decisions arising from past problems than those who come into a project without that perspective and think more about the requirements of the day. Both have their places, of course.
What other databases are you using?
I have used a bunch in the past – MySQL, HBase, MongoDB, Redis, CouchDB, SQLite, Firebird, Neo4J, and others.
While PostgreSQL is my favorite, there are certainly points to appreciate about others. SQLite is dramatically underappreciated, for example, and is probably the only database management software I know of which is as extensible as PostgreSQL. If you need a database embedded in your application, I would recommend SQLite without any hesitation.
On which PostgreSQL-related projects are you currently working?
PostgreSQL code review occurs every other month in an organized effort called a “commitfest.” One of my new projects is a blog series for the TimescaleDB blog which focuses on a review of a few patches I find significant and why. Sometimes these are accepted and committed. Sometimes they are returned with feedback. The goal is to explain to those who are not contributing code to PostgreSQL how the development works and what we are likely to find in future versions. The latest in the series at this writing covers the commitfest forNovember 2022.
I am also packaging LedgerSMB for Gentoo Linux. LedgerSMB is a free/open source accounting and small business management system which runs exclusively on PostgreSQL and exports functionality to other applications via user defined functions.
How do you contribute to PostgreSQL? Any contributions to PostgreSQL which do not involve writing code?
While I have contributed one patch that was accepted (and a few more that were not), most of my contributions have been in areas other than coding. I have been on conference call-for-papers committees, and have actively presented at many PostgreSQL conferences around the world. Probably my favorite presentation was given at the Devroom at Fosdem 2023 on the need for human factors training for database teams. This talk excites me because I think we still address hupan error poorly as an industry and this is a step towards trying to improve that. However, I think I am better known for talks such as PostgreSQL at 20TB And Beyond, which discusses the high-trhoughput systems I worked on when I was on the database team at Adjust.
I have also just simply pushed the limits and reported bugs. It is really satisfying when a bug report leads to improvements in the software, especially in a software system as robust as PostgreSQL.
What I really like doing, though, is just going out and encouraging others to get involved. Sometimes I suggest others submit to conferences, or talk at meetups, etc. Spreading involvement around is something which strengthens all of us.
What is your favorite PostgreSQL extension?
If I have to pick one extension that makes my life easier, it would be plperl. I know Perl is somewhat out of fashion these days, but as a trusted language, you can do things with Perl in the database backend that would be much harder, or perform much worse in plpgsql. And with immutable functions and functional indexes, this opens up a lot of possibilities and can be used even in most managed database service offerings.
For example, one time I added an immutable Perl function to extract the patent date out of a row containing a document describing a patent. We then indexed the output of that function and could then order patents without a lot of extra work. Doing that in another language would have been far more painful.
What is the feature you like most in the latest PostgreSQL version?
The ability to replicate only a subset of changes on a logical slot is something that I see as extremely useful. I have, in past projects, written my own filtering replication systems and this represents a great step forward for cases where you want to share a subset of information with an external entity for various partnership reasons, or where you might want to publish only records where certain checks have been completed.
When you add the feature that was just committed for PostgreSQL 16, which allows replication cycles, logical replication is becoming very powerful in PostgreSQL.
Adding to that, what feature/mechanism would you like to see in PostgreSQL? And why?
One of the big problems with logical replication in PostgreSQL is no ability to fail over. It would be very good to get this solved especially since the trend is to support more and more complex replication topologies. As logical replication becomes a larger feature in PostgreSQL, the ability to handle a server outage will become more important and right now that is difficult in complex cases.
Which skills are a must have for a PostgreSQL developer/user?
If I am looking for the skills that most benefit PostgreSQL developers and users, I would say that there are two primary ones: the ability to learn and a willingness/ability to think in formal math and logic where required. Relational databases implement mathematics (and arguably SQL as a language implements that math badly), but if we understand that math, we can avoid a lot of unnecessary difficulties.
As mentioned, the ability to learn is really important too. PostgreSQL is a system where the basics can be learned quickly, but one can spend a lifetime studying it and learning more. The PostgreSQL codebase is well over a million lines, and whether you are a user or developer, there will be corners of the software you haven’t explored yet and may never even get to in your career.
I think it is worth describing what I see as one likely progression in PostgreSQL-related careers. At the beginning of our careers with this database, most of us start out with relatively small databases and simple problems, such as writing queries and the like. However, if we end up in larger environments (and these are becoming more common) we have to learn how to think about how PostgreSQL works inside. Getting from one to the other requires developing good self-learning habits, being willing to admit what you don’t know, and accepting when you are wrong.
Which PostgreSQL conferences do you visit? Do you submit talks?
I have generally attended PGConf.EU even without speaking. I have also attended and spoken at PGConf.NYC, FossAsia Summit (which has a database track), and many others. In general my conference schedule changes from year to year.
Do you think PostgreSQL has a high entry barrier?
Back in 1999, it definitely did. Today I don’t think so. In the meantime, PostgreSQL has had a lot of features added which have made it much easier to use and maintain. Today I think PostgreSQL is a lot more approachable than it used to be, and part of this is due to the community focusing on the user experience and clarity. I think the result is an ever more approachable project. Of course we can always do more, but as we continue to grow, we will do more just because more people will contribute in all kinds of ways (not just code).
What is your advice for people who want to start PostgreSQL developing - as in, contributing to the project. Where and how should they start? What about non-code contributions?
For code contributions, my advice would be to start by reading the -hackers email list and reviewing commitfest submissions you find interesting. This is a great way to get embedded in the community, see how commitfests operate, and so forth. From that point, propose your changes before you have code and see who complains or says they want them. Especially in your first few submissions it can be nice to work with more established folks. For non-code contributions, my advice is find something that is interesting to you, and start working on it. And bring in others. All contributions are better done with others, and that is part of the fun. If you see something that people could benefit from, start doing it. If others are already involved, join them. One thing the PostgreSQL community does quite well in my experience is accepting and valuing a wide range of contributions besides code.
Do you think PostgreSQL will be here for many years in the future?
Absolutely. In fact, I will suggest that it is likely that PostgreSQL will continue to move forward in dominating the general purpose relational database system market for years.
Would you recommend PostgreSQL for business, or for side projects?
Yes. For both. You need the side projects to get started learning, and it is an incredible database engine for business projects of any size.
Are you reading the -hackers mailinglist? Any other list?
What other places do you hang out?
I am often on both IRC and Slack. They are different environments now with increasingly different crowds. I used to be pretty heavily involved on StackOverflow and the DBA Stackexchange site too, though not so much anymore.
Which other Open Source projects are you involved or interested in?
I am still involved in LedgerSMB, which is an open source accounting, invoicing, supply chain management, etc program written with small to mid-sized businesses in mind.
I am beginning to get involved with Gentoo Linux as well. Gentoo is an extremely flexible source-based Linux distribution, as they say. I look at it as an ideal toolkit for building your own distributions, and the packaging system is both beautifully simple and extremely powerful.
I have a number of other small related open source projects scattered around. Those are the major ones though.