Dimitri Fontaine

Reading time: 9 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, your hobbies and where you are from.

Hi! My name is Dimitri Fontaine and I’m French, currently living in the greater Paris area. When I’m not sitting in front of a computer for work, I like to be with my kids. We play board games, have fun chats, watch movies together… well or at least try to find a single movie that we would each enjoy watching… I also play the guitar.

Not truly a hobby, though it certainly started that way, I also wrote a book to help application developers appreciate how much you can do with Postgres. It’s named “The Art of PostgreSQL”, check it out!

Any Social Media channels of yours we should be aware of?

I’m retweeting a lot of PostgreSQL content on my twitter account @tapoueh. I also write articles in two blog areas: both tapoueh.org and the one from my book’s website, with another series of articles at theartofpostgresql.com/blog/.

When did you start using PostgreSQL, and why?

I think my first exposure to PostgreSQL was in my university years, around 1998 or 1999, something like that. The local sysadmin didn’t have enough time to also be a DBA, and because I was the one who asked him to provide us with an RDBMS in the first place, he gave me the Unix privileges to admin the database service. We were using an HP-UX server, and installing PostgreSQL (from sources) was easy there: it took me many years to realize that was no coincidence: thanks again Tom Lane!

Do you remember which version of PostgreSQL you started with?

I think my first serious usage of Postgres happened in the context of managing production for some company and that was with 7.2 up to 7.4. Which means I remember about some very old Postgres versions as giant steps forwards…

Have you studied at a university? If yes, was it related to computers? Did your study help you with your current job?

Apparently as a very small kid I had a dream that one day I would be an “engineer”. I think I had no idea what that could even mean. I made it true though, thanks to the public education system we have in France. So yeah I did 5 years of computer science related studies: an I.U.T of “Génie Informatique” (CS basics) and then a university of computing science again. From there I got a pretty good introduction to the Unix Operating System and its influence in the Internet design, and some other cultural bits allowing one to compare assembly, Ada, and C programming. Nothing much practical such as using CVS or the like, though. In our RDBMS class for instance we would learn about normalisation and query planning, but not how to write SQL queries…

What other databases are you using? Which one is your favorite?

In the context of the pgloader tool I sometimes have to work with other databases… but only in the context of migrating them to Postgres. Then at work I am confronted with using Citus, an extension to Postgres that makes it a distributed RDBMS. So that’s still Postgres, in most ways.

My favorite RDBMS is Postgres, no doubt.

On which PostgreSQL-related projects are you currently working?

My current full time job is spent improving pg_auto_failover, an Open Source project to provide Fault Tolerance by implementing an automatic failover solution for running Postgres in production. We have production grade users of the tool already, and we are working on release 1.3 at the moment. pg_auto_failover is meant to be very easy to use and to just work with simple architectures. Though to be honest version 1.4 should keep the simplicity and add quite some flexibility in terms of production architectures supported.

Another project that still gets some of my attention is pgloader: a fully automated tool used to load data in Postgres, and also to migrate a whole database in a single command. It can be as simple as pgloader mysql://user@host/dbname pgsql://user@host/dbname, and you’re done with the schema and data! I would like to create a team around the project, so if you are interested, please join us: find an issue, reproduce it, then hack your way around it and fix it. Open a PR and ask for help, I’ll be happy to give a hand and welcome new contributors!

How do you contribute to PostgreSQL?

I used to contribute code to Postgres, when I developed the CREATE EXTENSION and CREATE EVENT TRIGGER commands, back in the 9.1 and 9.3 era. Nowadays I contribute through pg_auto_failover and pgloader in terms of free software, through speaking at conferences, and through my book The Art of PostgreSQL.

Any contributions to PostgreSQL which do not involve writing code?

The speaking engagements and the blogs and the book are not code, and still benefit the community at large, so yeah, there’s that.

What is your favorite PostgreSQL extension?

That’s a hard question. I think I’m going to have to go meta here and say that I love that Postgres allows users to install extensions and developers to come up with very interesting ones to answer compelling use cases. It would be hard for me to make a single choice of a favorite extension, there are so many to choose from!

What is the most annoying PostgreSQL thing you can think of? And any chance to fix it?

I think that we could improve discoverability of features in Postgres. We have so many things in there that are not easy to find or understand the impact of. For instance, let’s mention the humble generate_series() SRF. It’s a Set Returning Function that is included in Postgres and allows solving quite advanced problems in an easy way. Another such example would be partial unique indexes, that are so useful and almost impossible to replace at the application level without giant locks.

That’s why I wrote my book in the first place. I keep thinking we should give the Postgres documentation tutorial an overhaul, but also I keep failing to find time for my many projects and ideas…

What is the feature you like most in the latest PostgreSQL version?

Each and every version of Postgres comes with some level of automation of what would have previously been hard to tune parameters. Those kinds of improvements are among my favorites. Improving our support for the SQL standard is a close second, of course.

To summarize I like that Postgres allows its users to implement complex things in a simple way. It will do the hard work for you, and that’s something I enjoy!

Adding to that, what feature/mechanism would you like to see in PostgreSQL? And why?

When first introduced to the match_recognize clause of the new SQL standard edition (thanks Vik!), it took me a while to get my head around it. But then with the help of Markus' article about it at modern-sql.com/feature/match_recognize I now would very much like to see it contributed to Postgres.

Which skills are a must have for a PostgreSQL developer/user?

I think the most useful skill to have when using Postgres is application and system architecture. Understanding how the code you write is going to run in your production environment, and which component is offering what service, that’s the key to leveraging Postgres — and any other service you’re deploying, really.

I cringe each time I see Postgres approached as a “storage system”. If what you want to solve is storage, dump memory in XML or JSON files (or whatever format you like better, really), and provide an HTTP based API on top of that, or something, you know. Problem solved.

Postgres and RDBMS are solving the problem of concurrent access to a single data set. That’s not storage… and understanding this is a key, in my opinion, to understanding the appeal of complex SQL and sometimes even stored procedures. Being able to visualize an application run-time system as a whole is a complex task, and requires training and patience. I think it’s the most useful to have as an application developer though.

Which PostgreSQL conferences do you visit? Do you submit talks?

Well nowadays we’re under lock-down and that might continue for a while. I hope we can maintain PostgreSQL Conference Europe later this year and would be delighted to participate. Among my favorite Postgres conferences are pgDay Paris and Nordic PGDay, PGCon in Ottawa, and then some more. I have been so lucky to travel the world to meet people in São Paulo (Brazil) and Tokyo (Japan), for instance!

Do you think PostgreSQL has a high entry barrier?

I think many users of Postgres are not too sure why they’re using that piece of technology or what’s special about it. Mostly because developers are hired in an existing project which is already using Postgres, and in general with several layers of abstraction on top of it. When I have attended programming language meetups and conferences, I have had chats with developers who would use Postgres because it’s what their favorite web framework uses. Lots of users never get to the point of having to ask why they are using Postgres.

So yeah, we could do a much better job at explaining the role of Postgres in a production ready application stack, from the point of view of the application developer.

What is your advice for people who want to start PostgreSQL developing - as in, contributing to the project. Where and how should they start?

When Lætitia asked me the same questions, my answer was to find either a very simple and crystal clear bug to fix, or a missing bit from the SQL standard. As Postgres bugs are usually fixed same-day, it’s quite hard to be successful that way, so maybe that’s good training to still do it and then compare with what ended up committed, as a learning curve.

Do you think PostgreSQL will be here for many years in the future?

No doubt. Who wants to implement an alternative, from scratch, with that level of completeness? Again, if you think about concurrent access to a single data set… Well I know for one that I’m very happy to not have to solve that in my own application code. That’s why even pg_auto_failover uses Postgres for its monitor, after all.

Would you recommend PostgreSQL for business, or for side projects?

Both, of course.