An Oracle DBA’s Introduction to PostgreSQL – The New Reality

Back in 2004, I had my first run-in with PostgreSQL’s predecessor: Ingres. It was just another database platform for me to know, as I was already managing Oracle, SQL Server, Sybase and DB2, and as usual, there was no one else in the room. I vaguely remember working through the mechanics of VACUUM and maintenance routines, but much of it faded into the background as my career led me deeper into the world of Oracle, SQL Server and MySQL databases. At the time, PostgreSQL was still finding its footing, and Ingres seemed like a legacy product already slipping into obscurity.

Fast-forward almost two decades, and PostgreSQL is not only relevant, but also thriving.  The Oracle world will tell you it’s not and the PostgreSQL world will tell you it’s already migrated everything off Oracle.  The truth is, neither is true and I laugh at anyone who starts on this tired topic.

I was reintroduced to PostgreSQL through Google’s AlloyDB Omni, a downloadable version of their PostgreSQL-compatible database engine built for hybrid and on-prem environments. I spent time running performance benchmarks outside the Google Cloud ecosystem just to see how it would behave in the wild. I was surprised in a good way on performance and was offered the opportunity to observe it mature from its infancy, which was incredibly interesting. As a whole, I believe PostgreSQL has matured into a serious contender, especially for greenfield projects and AI-adjacent workloads.

Over the past two years, I’ve leaned on PostgreSQL for an initial AI project that needed something fast, flexible, and cloud-agnostic. It’s open source, well-documented, and offers the opportunity for licensing investment required for enterprise platforms to be invested elsewhere. The performance tuning I did echoed some of the familiar patterns from Oracle, but with enough key differences to keep me on my toes, no matter if we were talking about benchmark tools or SQL tuning.

Why PostgreSQL Should Be on Your Radar

Many enterprise environments are adopting a hybrid database strategy: maintaining Oracle, SQL Server, or other licensed platforms for mission-critical applications, while transitioning secondary or less business-sensitive workloads to open-source platforms like PostgreSQL. This model balances performance, risk, and cost, like I said – freeing up budget while still ensuring enterprise-grade features required by most traditional workloads.

Img. 1:  Don’t ask me why PostgreSQL is off-center, AI has a mind of it’s own… 🙂

That shift puts database professionals in an interesting spot. Whether you’re an Oracle or SQL Server expert, or somewhere in between, you’re likely to encounter PostgreSQL in-house, if you haven’t already. This means:

• You’ll need to monitor PostgreSQL as part of your data estate.
• You need to understand how PostgreSQL handles security, backup, and replication.
• You’ll want to get familiar with PostgreSQL’s optimizer, indexing strategies, and query tuning nuances.
• You’ll be expected to integrate PostgreSQL with CI/CD pipelines, containers, and monitoring stacks, which is often different from what you’re used to in Oracle.

A Multiplatform Reality : Team Kellyn!

Let’s face it- the era of being a one-platform database expert is over. Organizations are building polyglot persistence layers with full-stack developers, (I know you’re snickering over there!) and they expect their database teams to be just as versatile.

For Oracle DBAs, the transition to PostgreSQL isn’t as jarring as you might think. There are familiar features like roles, tablespaces, functions, and even stored procedures (thanks to PL/pgsql). But PostgreSQL also comes with its own unique philosophies: MVCC by default, strong community-driven governance, and a more transparent extension ecosystem.

What’s Next?

This post is just the start. In the upcoming series, I’ll break down PostgreSQL for the Oracle DBA, covering things like:

• Understanding PostgreSQL architecture vs. Oracle’s
• How PostgreSQL handles indexing, execution plans, and performance tuning
• Setting up PostgreSQL for high availability and failover
• Managing users, roles, and security the PostgreSQL way
• Extension management and what’s safe (or not) to use in production

If you’re an Oracle DBA looking to get ahead of the curve or already facing a mixed-database environment, you may want to keep following along as I build out this next blog series.  I haven’t forgotten the Oracle Basics posts – those will continue, too, but in the meantime, let’s make PostgreSQL one more tool you wield with confidence and not just with frustration!