Postgres vs. PostgreSQL

I have been with the project long enough to remember how the project got the name "PostgreSQL". In 1996, we inherited the name "Postgres95" from the Berkeley team's remaining member Jolly Chen. Obviously the Postgres95 name wasn't going to last long-term, so a new name had to be chosen. We could revert to the original Berkeley name "Postgres", or go with a name that more closely identified us as an sql database and call it "PostgreSQL".

To add complexity to the discussion, Berkeley Postgres (before Postgres95) used the quel query language, so there were valid arguments that we needed to advertise that the database now used sql. After heated debate, "PostgreSQL" was chosen, and "Postgres" was later accepted as a valid alias.

Enterprise-ready Postgres tools for high availability, monitoring, and disaster recovery. Download Now.

I was always in the "Postgres" camp, but over time I have learned to appreciate the arguments of those who prefer "PostgreSQL". The two strong arguments for "PostgreSQL" are:

-- Visually better than "Postgres"

-- Identifies it to new people as an sql database

The strong argument for "Postgres" is that "Postgres" is simpler to say, while "PostgreSQL" is complex and has several verbal options, e.g. Postgres-Q-L, Postgres Sequel", Postgre Sequel".

What has really cemented my appreciation for both names is that the companies I have worked for have cycled through the two names because they saw value in each one. What that tells me is that both names have unique value and that we have to do our best to leverage the strengths of both.

Also, from the further obscure closet, here is the first email suggesting that Postgres use an elephant as its mascot:

      but if you want an animal-based logo, how about some sort of elephant? After all, as the Agatha Christie title read, elephants can remember ...

Bruce Momjian is a Senior Database Architect at EnterpriseDB.

This post originally appeared on Bruce's personal blog.