Interview With Bruce Momjian

Ingres and Informix.

(from his blog in http://momjian.us/main/faq.html)

In 1996, I had been using SQL databases at work for years, but I had no SQL database on my home Unix machine, and there weren’t any affordable ones available. I looked around and finally found PostgreSQL. It had features similar to the commercial databases I was using at work. I started using it and while it was powerful, it had lots of bugs, and the bug fixes weren’t being collected and released frequently enough. The software had potential, but it needed organization. I was always curious how SQL databases executed queries, and with PostgreSQL I could see the process in action, so I started digging into the code. I also learned a lot about programming complex applications, so I stuck around with the idea that the new skills I learned might be helpful someday, and as they say, the rest is history.

Uh, certainly high reliability and SQL standards, as well as easier administration and better performance.

Well, when I started we kind of just improved PostgreSQL to meet the needs of users. We never had any grand plan on where we were going 10 years in the future. Now we are equal in functionality to most commercial databases, and a lot of companies are using PostgreSQL. That
is certainly a new development. I imagine we will continue to have companies switching to use us.

I do mostly project administration and lots of little jobs no one else wants to do.

No, I think it will remain a community process, rather than company-drive. The companies involved now all realize that they can’t improve on the process we have now.

We always had companies that wanted to switch to us but the cost of switching was more than the money they were going to save with PostgreSQL. EnterpriseDB makes switching less costly. The community doesn’t seem too worried about switching cost because we are mostly
focused on people doing new projects or people who are willing to recode their applications to work on PostgreSQL.

Uh, mostly it is in automatically setting certain postgresql.conf configuration parameters, and a few improvements that will appear in the next PostgreSQL release.

They have assigned a number of developers to work full-time on community improvements that will be in the next release of community PostgreSQL. They have a few big features that will probably be in 8.3. They are also funding some folks to help review patches.

I don’t see a fusion. The good news is that companies have identified where they can work to improve PostgreSQL while allowing the community to continue to grow at great speed.

Uh, good question. The Korry Douglas book seems very good. I am not sure what other books are needed. The PostgreSQL community documentation is pretty good.

12 – Replication solutions to PostgreSQL have had a lot of attention of developers at PostgreSQL history. We see a lot of projects that become dying in a few years. Slony II was a recent example. What make too many projects of this kind die so fast?

Replication is hard, a lot harder than most people think, even for the commercial database. We had a number of attempts to follow new replication research that we hoped would make replication better, but sometimes it doesn’t work properly, like Slony II. My guess is that we
are going to have to limit the number of replication things we try and take a more conservative approach.

There was a talk about that recently at the PostgreSQL conference in Ottawa and the author said there were still performance issues with PGCluster II. We will see if these can be fixed.

Yes, I think we are getting closer every year. We have come so far in the past 11 years that certainly we can reach that level of functionality.

Historically we were mostly online transaction processing (OLTP) but have added data warehousing and other features in the past few years as people asked for them. I think we will continue to spread to new areas.