My first introduction to PostgreSQL was back in the summer of 2001. As I type this, I realize that this was fifteen years ago.
I was volunteering with the folks who maintained Portland IndyMedia, which was a local resource for activists of all flavors. It allowed the public to post news articles, share photos, announce events, and discuss things that were a concern to them. The project was originally started in 1999 as a tool to support protestors during the Seattle WTO demonstrations. The code base was open-sourced and people would setup their own instance in their corner of the world.
As a volunteer, I began helping with small code updates to fine tune the project to our liking in Portland. The code base was primarily written in Perl with a PostgreSQL backend. I’m pretty sure my first contributions were a few database indexes.
The following year, I began working for a small development shop in Portland that worked on various Perl, Python, and PHP projects. My bosses had co-authored O’Reilly’s PostgreSQL book … so it probably goes without saying that it was our go-to for open source data storage.
As I quickly learned, MySQL wasn’t always the most reliable nor robust database. We were hired to work on a number of migration projects once companies encountered some nasty data integrity issues. At this point in my career, I was working on a number of projects where multiple code bases were sharing the same database so we heavily relied heavily on stored procedures, triggers, custom validation rules, and other sophisticated features that PostgreSQL afforded us. I was taught to never trust the application code to properly validate data.
At the end of the day, MySQL was fast at a lot of what it did but not being ACID-compliant was a deal-breaker for many of our larger clients. MySQL has since improved much of this, but it was too litte, too late for us.
This was pre-ORM days for me.
Toward the end of 2004, I began toying around with Ruby on Rails. David was (and still is) a fan of MySQL. Admittedly, I was initially a little skeptical about ActiveRecord due to this. While Ruby on Rails aimed to be database-agnostic, I was worried that it wasn’t going to work too well with PostgreSQL.
My first Rails projects were built on top of existing PostgreSQL databases that had existing triggers, data constraints, and custom types. It wasn’t the simplest type of database to build a Rails application with. I was hitting some odd issues here and there. Eventually, this led to my first contributions to the Ruby on Rails code base. I was finding some quirky data issues when I removed triggers in my database and tried to rely on ActiveRecord’s callbacks. I later helped with this.
For those who were around during the first year of Ruby on Rails, you might remember Tobias Lutke’s open source blogging engine called Typo. I contributed the initial PostgreSQL database schema. That’s right folks, back in 2005, we were hand coding our database schemas because migrations didn’t come for maybe a year later? Developers these days missed out on all the “fun.”
(I still have nightmares about versioning schema migrations)
Anyhow, I was loud and proud about my love for PostgreSQL. Over time, I found a nice compromise between relying on ActiveRecord as the security person at the door and PostgreSQL as the bouncer inside the club. (this was how Jeremy Voorhis and I described this on the Ruby on Rails podcast in the spring of 2006)
I might have developed a bit of a reputation for debating this with people.
A decade has since past. Where are we now in the community? While I’d love to take some credit for the huge swing from MySQL to PostgreSQL, I can’t help but credit folks like Heroku for getting people comfortable with it.
In 2016, we see that PostgreSQL is the preferred database by 84% of the Ruby on Rails community. This is 12% increase over the 2014 results. What we’re also seeing is a variety of other database technologies continuing to be used for certain types of projects.
MySQL is still preferred by 14% and in my own opinion, I predict that in five years we’ll see it lingering in the ~10% range given that so many existing applications were already developed with it. With PostgreSQL adopting Andl in an upcoming release, I stand confident that it’ll continue to dominate the open source community.
Long live PostgreSQL; long live Ruby on Rails.
p.s. Did you know that you can write stored procedures in Ruby within PostgreSQL? I miss playing around with those sorts of features.
 1417 people responded to the 2016 community survey.