{"id":113006,"date":"2026-10-01T12:00:00","date_gmt":"2026-10-01T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=113006"},"modified":"2026-09-29T15:08:55","modified_gmt":"2026-09-29T15:08:55","slug":"why-postgresql-shouldnt-be-your-apps-answer-to-everything","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/postgresql\/why-postgresql-shouldnt-be-your-apps-answer-to-everything\/","title":{"rendered":"Why PostgreSQL shouldn’t be your app’s answer to everything"},"content":{"rendered":"\n

PostgreSQL is one of the most capable relational databases available, but capability isn’t the same as suitability. <\/strong><\/p>\n\n\n\n

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<\/strong>, single points of failure<\/strong>, security exposure<\/strong>, and rising cloud costs<\/strong>. <\/p>\n\n\n\n

PostgreSQL expert Pat Wright <\/strong>explains more.<\/p>\n\n\n\n

Stop putting everything in the database!<\/h2>\n\n\n\n

I\u2019ve seen quite a few posts lately about how PostgreSQL<\/strong><\/a> can do everything.<\/em> And, while I do believe it’s the most advanced and fastest-growing relational database<\/strong><\/a> available right now, that doesn\u2019t change the fact that – at its core – it’s still a relational database.\u00a0\u00a0<\/p>\n\n\n\n

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

Even back then, people said these new technologies could solve every problem<\/em>. Take it from me: please don’t use any<\/em> technology for every<\/em> problem you have.<\/strong><\/p>\n\n\n\n

I\u2019ve spent a lot of my career fixing systems that said, \u201clet\u2019s have the database handle this.\u201d<\/em>\u00a0 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.<\/p>\n\n\n\n

You can<\/em> put all of these things in the database – but that doesn’t mean you should<\/em>.<\/strong><\/p>\n\n\n\n

Why engineers keep putting everything in the database<\/h2>\n\n\n\n

Now that I\u2019ve probably upset a few engineers with these points, let me clarify a few things. <\/p>\n\n\n\n

First off, I\u2019m a DBA – typically, an operational DBA.<\/p>\n\n\n\n

What is an operational DBA?<\/h3>\n\n\n\n

Being an operational DBA means I\u2019m the one who has to deal with what was created years ago<\/em> just to get an application out the door.<\/strong><\/p>\n\n\n\n

It’s the same little puppy (the application) that was once cute and cuddly \u2014 the one everyone laughed at when it left tiny bite marks on your shoes.<\/p>\n\n\n\n

Now, that very same puppy consumes 32 pairs of shoes a day and costs your company thousands of dollars in cloud costs<\/a>.<\/p>\n\n\n\n

\n
\n\n

You may also be interested in…<\/strong><\/p>\n\n\n\n

What does a modern DBA actually do? 6 key points from a senior DBA <\/a><\/p>\n\n\n\n

How to migrate from on-prem to the cloud (a \u2018DBA Stories\u2019 series)<\/a><\/p>\n\n<\/div>\n<\/div> \n\n\n

Why you might believe you can <\/em>put everything in the database<\/h3>\n\n\n\n

Look, I understand why you believe you can put things like this in the database, I really do. I\u2019ve been in these discussions many times, and know these statements well:<\/p>\n\n\n\n

\u201cWe are going to refactor in 6 months.\u201d\u00a0<\/em><\/p>\n\n\n\n

\u201cThis is just for MVP (minimum viable product). We will add tickets to refactor.\u201d\u00a0<\/em><\/p>\n\n\n\n

\u201cWe only had 2 months for this to be released.\u201d\u00a0<\/em><\/p>\n\n\n\n

\u201cSomeone already wrote a driver\/connector that does this, so we should be OK. We can just use that to save time.\u201d\u00a0<\/em><\/p>\n\n\n\n

\u201cWe don\u2019t have to do any extra coding! Just hand it to this extension and it’s taken care of!\u201d\u00a0<\/em><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

So, why exactly am I against<\/em> adding things to the database?\u00a0<\/strong><\/p>\n\n\n\n

\n
\n
\n
\n

Get started with PostgreSQL – free book download<\/h3>\n
\n ‘Introduction to PostgreSQL for the data professional’, written by Grant Fritchey and Ryan Booz, covers all the basics of how to get started with PostgreSQL. <\/div>\n <\/div>\n Download your free copy<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n

The 4 key reasons to stop putting everything in your database <\/h2>\n\n\n\n

Here are some of the key reasons, from my perspective, to stop putting everything in the database.<\/strong><\/p>\n\n\n\n

Unclear code ownership<\/h3>\n\n\n\n

It\u2019s universally known that engineers own the code. They own how it works and what it does.<\/p>\n\n\n\n

However, database<\/em> code is gray area for a lot of companies. Sometimes database folks own the database<\/a> and the procedures inside it, and sometimes ownership is split between engineers and<\/em> DBAs.<\/p>\n\n\n\n

Ultimately, engineers LOVE to own things. They need to understand how things work and be able to change them quickly. <\/p>\n\n\n\n

And, when you put stuff into a database, you inadvertently create a big gray area about who owns it when things go wrong.<\/strong><\/p>\n\n\n\n

Who, for example, gets the call at 2am if the extension breaks? <\/p>\n\n\n\n

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<\/em>.<\/p>\n\n\n\n

Single point of failure<\/h3>\n\n\n\n

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<\/strong>, since they’re all connected.<\/strong> <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.\u00a0<\/p>\n\n\n\n

Security and governance risks<\/h3>\n\n\n\n

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\u2019t access data it shouldn’t?\u00a0 <\/p>\n\n\n\n

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

The more database access points you give others, the more you expose your data.<\/strong>\u00a0<\/p>\n\n\n\n

Again, separation can help here, but I don\u2019t see it enough.\u00a0\u00a0<\/p>\n\n\n\n

\n
\n\n

You may also be interested in…<\/strong><\/p>\n\n\n\n

How to keep your databases secure in 2026: a complete guide<\/a><\/p>\n\n\n\n

Simple Talk’s full collection of data and database security, privacy & compliance guides<\/a><\/p>\n\n<\/div>\n<\/div> \n\n\n

Rising infrastructure costs<\/h3>\n\n\n\n

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\u2019m pretty sure the database will be one of your most expensive components. <\/p>\n\n\n\n

Being open-source, PostgreSQL doesn’t have any licensing costs to deal with – but it does<\/em> have expense connected to CPU, memory, and disks. <\/strong><\/p>\n\n\n\n

And, to put it simply: the more services, extensions, and work you throw at the database, the more it will cost.<\/strong> <\/p>\n\n\n\n

Queuing, for example, is much cheaper with a queue service outside<\/em> of the database. <\/p>\n\n\n\n

So, while you may gain some<\/em> simplicity with putting things in the database, you’re going to spend more in doing so.<\/p>\n\n\n\n

In summary…<\/h2>\n\n\n\n

I know this won’t change the minds of people who genuinely believe PostgreSQL can do everything<\/em>. 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.”<\/em><\/p>\n\n\n\n

My hope, then, is that you spend some time thinking about what truly needs to be in the database<\/strong>, and what it means for the future. <\/p>\n\n\n\n

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

For everyone else, well, I\u2019m still available for consulting and fixing the decisions you made previously! Just give me a call.\u00a0<\/p>\n\n\n\n

What do you think? I’d love to hear your thoughts in the comments down below.<\/em><\/strong><\/p>\n\n\n\n

\n
\n
\n
\n

Free desktop tool for fast PostgreSQL monitoring and diagnostics<\/h3>\n
\n Stay in control of PostgreSQL performance with Redgate pgNow \u2013 a free desktop tool for fast, focused diagnostics. No agents, no setup, just actionable insights when you need them. <\/div>\n <\/div>\n Learn more & download now<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n
\n

FAQs<\/h2>\n\n

1. Can PostgreSQL handle queuing, caching, and document storage?<\/h3>\n
\n

Yes, because PostgreSQL’s extension ecosystem makes almost anything possible – but doing so often tightly couples unrelated systems, so a single failure (like a stuck queue) can take down the whole application. Each added workload then increases the database’s cost and attack surface.<\/p>\n <\/div>\n

2. Why is putting a queue inside the database risky?<\/h3>\n
\n

When a queuing system lives inside the same database as the rest of the application, it isn’t isolated. A queue backup or failure can cascade into a full production outage, since the queue and the application share the same resources and failure domain.<\/p>\n <\/div>\n

3. Who owns database extensions when something breaks?<\/h3>\n
\n

Ownership is often unclear. Engineers typically own application code, but database-level logic \u2014 extensions, procedures, embedded services \u2014 frequently falls into a gray area between engineering and DBA teams, which slows down incident response.<\/p>\n <\/div>\n

4. Does adding extensions to PostgreSQL increase cloud costs?<\/h3>\n
\n

Yes. Every extension or embedded service adds CPU, memory, and disk demand to the database tier, which is usually already one of the most expensive parts of a cloud bill. Running the same workload (e.g. queuing) outside the database is typically cheaper.<\/p>\n <\/div>\n <\/section>\n","protected":false},"excerpt":{"rendered":"

A DBA explains why using PostgreSQL for queuing, caching, or document storage creates ownership gaps, security risks, and higher cloud costs.…<\/p>\n","protected":false},"author":346611,"featured_media":113061,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143523,53,143534],"tags":[4168,4170,158978],"coauthors":[159379],"class_list":["post-113006","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-databases","category-featured","category-postgresql","tag-database","tag-database-administration","tag-postgresql"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/113006","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/346611"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=113006"}],"version-history":[{"count":20,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/113006\/revisions"}],"predecessor-version":[{"id":113094,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/113006\/revisions\/113094"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media\/113061"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=113006"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=113006"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=113006"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=113006"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}