PostgreSQL is one of the most capable relational databases available, but capability isn’t the same as suitability.

Using it to handle jobs it wasn’t built for – such as queuing or storing every document an application generates – creates recurring problems like unclear code ownership, single points of failure, security exposure, and rising cloud costs.

PostgreSQL expert Pat Wright explains more.

Stop putting everything in the database!

I’ve seen quite a few posts lately about how PostgreSQL can do everything. And, while I do believe it’s the most advanced and fastest-growing relational database available right now, that doesn’t change the fact that – at its core – it’s still a relational database.  

This thinking goes all the way back to the mid-2000s, when I was working on SQL Server and starting to explore the NoSQL movement with Elasticsearch, Hadoop, Hive, HBase, and their respective tools.

Even back then, people said these new technologies could solve every problem. Take it from me: please don’t use any technology for every problem you have.

I’ve spent a lot of my career fixing systems that said, “let’s have the database handle this.”  From fighting queuing in the database (a topic for another time), to using the database as a cache, or to store every document you’ve ever sent by email.

You can put all of these things in the database – but that doesn’t mean you should.

Why engineers keep putting everything in the database

Now that I’ve probably upset a few engineers with these points, let me clarify a few things.

First off, I’m a DBA – typically, an operational DBA.

What is an operational DBA?

Being an operational DBA means I’m the one who has to deal with what was created years ago just to get an application out the door.

It’s the same little puppy (the application) that was once cute and cuddly — the one everyone laughed at when it left tiny bite marks on your shoes.

Now, that very same puppy consumes 32 pairs of shoes a day and costs your company thousands of dollars in cloud costs.

Why you might believe you can put everything in the database

Look, I understand why you believe you can put things like this in the database, I really do. I’ve been in these discussions many times, and know these statements well:

“We are going to refactor in 6 months.” 

“This is just for MVP (minimum viable product). We will add tickets to refactor.” 

“We only had 2 months for this to be released.” 

“Someone already wrote a driver/connector that does this, so we should be OK. We can just use that to save time.” 

“We don’t have to do any extra coding! Just hand it to this extension and it’s taken care of!” 

OK, yes, PostgreSQL has the best extension ecosystem in the RDBMS (relational database management system) world. We’ve been promoting extension creation in the platform for a long time, and want to expand it further.

So, why exactly am I against adding things to the database? 

The 4 key reasons to stop putting everything in your database

Here are some of the key reasons, from my perspective, to stop putting everything in the database.

Unclear code ownership

It’s universally known that engineers own the code. They own how it works and what it does.

However, database code is gray area for a lot of companies. Sometimes database folks own the database and the procedures inside it, and sometimes ownership is split between engineers and DBAs.

Ultimately, engineers LOVE to own things. They need to understand how things work and be able to change them quickly.

And, when you put stuff into a database, you inadvertently create a big gray area about who owns it when things go wrong.

Who, for example, gets the call at 2am if the extension breaks?

As an engineer, you may be able to make something easier and faster by handing it off to a database (or another process), but remember – you may still have to own it.

Single point of failure

If you put your queuing system in the database and don’t separate it from the rest of your application, a single queue going down can take your entire production system down with it, since they’re all connected.

I’ve seen this happen many times. You may think the answer is simple – just separate them – but that’s not always possible within the architecture.

When something’s designed quickly, the queue and the application often end up tightly coupled – and that coupling tends to cause bigger problems down the road. 

Security and governance risks

Do you know what this additional thing you’ve added to your database actually has access to? Is it segmented enough to ensure it can’t access data it shouldn’t? 

I understand it’s not a rogue extension running around (since you’re probably controlling it through code), but remember, it’s another point of access to your database – a database potentially holding the organization’s most critical information.

The more database access points you give others, the more you expose your data. 

Again, separation can help here, but I don’t see it enough.  

Rising infrastructure costs

Every point I’ve listed here is a critical one, but many teams would put cost and expense at the top of the priority order. Check any cloud bill you have, and I’m pretty sure the database will be one of your most expensive components.

Being open-source, PostgreSQL doesn’t have any licensing costs to deal with – but it does have expense connected to CPU, memory, and disks.

And, to put it simply: the more services, extensions, and work you throw at the database, the more it will cost.

Queuing, for example, is much cheaper with a queue service outside of the database.

So, while you may gain some simplicity with putting things in the database, you’re going to spend more in doing so.

In summary…

I know this won’t change the minds of people who genuinely believe PostgreSQL can do everything. After all, we’ll keep seeing more extensions and more features that promise, “just put it in the database and it’ll solve all your problems.”

My hope, then, is that you spend some time thinking about what truly needs to be in the database, and what it means for the future.

If I get even just a few engineers to stop and think along these lines, that’ll be a success for me.

For everyone else, well, I’m still available for consulting and fixing the decisions you made previously! Just give me a call. 

What do you think? I’d love to hear your thoughts in the comments down below.