Confessions of a PostgreSQL DBA

Confessions of a PostgreSQL DBA

Circa 1988.  I entered the technology space, writing SAS/JCL on an IBM 3270 for the Federal Government.  There was something missing though. Countless merges, duplicate data filtering and large data sets all seemed like a horrible waste of resources and, more importantly, time. Not only that, SAS user guides filled my entire cubicle, making it nearly impossible to evolve the skill set quickly.

Late in the summer of 1988, word came from Washington, DC, that we were to be part of a pilot group running new technology that would change everything: Oracle 6. How exciting . . . and by the way . . . what is SQL?

I rode the Oracle wave for years, building a lucrative career/reputation for myself, as DBA, Developer and Tuning Specialist. I drank Oracle Kool-Aid like a fiend, fed on PL/SQL tips and techniques from Steven Feuerstein and fell asleep to more than a few Oracle Tech Press books.

At the height of it all, I entertained an invitation to Emerald City (Oracle Headquarters) to meet with a few architects to discuss a new Oracle Applications reporting engine.  Larry Ellison was my hero, and this was his castle. He was a South Side Chicagoan who made it big in Silicon Valley and just the very icon a small town kid from Indiana needed.  Ellison is brash, smart and ruthless, creating a powerhouse of an organization, rivaled by few – even today. I guess he is still my hero.

Circa 2000. With a loaded Acura TL, I headed to Silicon Valley to work for a small startup, comprised of ex-Oracle patriots building a messaging encryption platform. The cat’s meow – I had finally made it to the big time!

In September of 2000, economics became a word I needed to understand after leaving deep pocket organizations behind for a startup. I soon realized that small/medium companies did not have hundreds of thousands to spend on licensing Oracle. We needed another solution . . . we needed PostgreSQL.

I spent most of September/October cutting code in PL/pgsql from Oracle packages/procedures and functions to stand up the encryption platform on PostgreSQL. In those days, cheap did not come easily – Cygwin issues and Windows server crashes nearly halted deployment on Microsoft.  In the end, we got past the challenges and produced a cheaper, lighter and faster product using PostgreSQL as persistent storage.

Present Day.  Today, cheap IS easy – a whole lot easier than it was in 2000. Over the years, I’ve found PostgreSQL to be comparable to Oracle and faster. I’ve also found its procedural language, PL/PGSQL, to be an excellent alternative to Oracle PL/SQL. Receiving high-quality support from Oracle was always a challenge. With PostgreSQL, I have my choice of leveraging a large, vibrant development community or a commercial vendor, EnterpriseDB, for product support. While I will always be a Larry Ellison/Oracle fan, I now wave the PostgreSQL flag and encourage those weary of paying heavy fees to do the same.

I evolved my thinking about what makes a great database . . . 17 years ago.

You can too.

The team at RDX will help.

If you would like to learn more about how RDX and PostgreSQL can help your organization, please reach out and let us know:  info@rdx.com.

Leave a Reply

Your email address will not be published. Required fields are marked *