{"id":113078,"date":"2026-11-13T12:00:00","date_gmt":"2026-11-13T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=113078"},"modified":"2026-10-22T13:34:41","modified_gmt":"2026-10-22T13:34:41","slug":"postgresql-extensions-why-the-fud-is-wrong","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/postgresql\/postgresql-extensions-why-the-fud-is-wrong\/","title":{"rendered":"PostgreSQL extensions: why the FUD is wrong"},"content":{"rendered":"\n

PostgreSQL’s biggest technical advantage is its extensibility. Extensions like PostGIS, TimescaleDB, and pg_stat_statements<\/code> let you reshape the database for time-series data, geospatial queries, performance monitoring, and more. <\/strong><\/p>\n\n\n\n

However, critics often push back with fear, uncertainty, and doubt (FUD) – extensions are hard to maintain, get abandoned, aren’t supported in the cloud…<\/em> Those claims contain some<\/em> truth, but are mostly overstated. Here’s why.<\/strong><\/p>\n\n\n\n

What is FUD?<\/h2>\n\n\n\n

There’s a phrase I’ve been using for a long, long time (have I said lately that I\u2019m old?)<\/p>\n\n\n\n

That phrase is fear, uncertainty and doubt (FUD).<\/strong><\/p>\n\n\n\n

I always thought that it had it\u2019s start somewhere in politics. However, a quick search finds that it has two beginnings. The first was in the 1920s when it was coined as a sales tactic, but it kind of fell out of favor. <\/p>\n\n\n\n

Then, in 1975, Gene Amdahl<\/a><\/strong> – working to create a competitor to IBM<\/strong><\/a> – brought it back to life, funnily enough by talking about the IBM sales reps. I guess the phrase fell out of favor, but not the sales concept.<\/p>\n\n\n\n

Basically, it\u2019s a way to cast something in a bad light. That way, the thing you want, or the path you\u2019re hoping to go down, looks better by comparison. Honestly, though, it’s just a tad evil in my opinion.<\/p>\n\n\n\n

Why (and how) does FUD target PostgreSQL extensions?<\/h2>\n\n\n\n

As a big proponent of PostgreSQL<\/strong><\/a>, the number one technical reason (again, in my opinion) to use PostgreSQL is the inherent, engineered-from-the beginning extensibility<\/em> of the tool.<\/strong><\/p>\n\n\n\n

Need to work with time-series data<\/a><\/strong>? There\u2019s a specific extension, TimeScaleDB<\/strong><\/a>, that turns PostgreSQL into the time-series king.<\/p>\n\n\n\n

Want to have a way to query performance metrics, similar to the DMVs in SQL Server<\/strong><\/a>? Great, you can use pg_stat_statements<\/strong><\/a><\/code> for that.<\/p>\n\n\n\n

There are simply hundreds of these – from little tiny functions to huge, new, wildly-effective capabilities that completely change what PostgreSQL can do.<\/p>\n\n\n\n

Yet, I hear all the time (especially while talking to people who are dedicated to their old platforms):<\/p>\n\n\n\n

\u201cWell, sure. You can use an extension, but did you know:
A) They have to be maintained, upgraded, and possibly administered, independently of PostgreSQL itself.
B) You\u2019re dependent on a team or individual to keep them up to date and they get abandoned.
C) Cloud providers don\u2019t support a lot of extensions.”<\/em><\/p>\n\n\n\n

I mean, yikes. You really want that kind of headache in your production database?\u201d<\/p>\n\n\n\n

Well, while all three statements have some truth to them, this is very much FUD. Let me explain why.<\/p>\n\n\n\n

Do PostgreSQL extensions require independent maintenance?<\/h2>\n\n\n\n

I intend to be fair, open and honest in this conversation. It’s 100% true that extensions will have to be maintained. For that maintenance, in this discussion, I\u2019ll focus primarily on keeping them updated. <\/p>\n\n\n\n

Yes, there\u2019s potentially other things you have to worry about as well (depending on the extension), but versioning and upgrades are two of the biggest issues that the FUD people<\/em> bring up.<\/p>\n\n\n\n

How extension upgrades work across databases and clusters in PostgreSQL<\/h2>\n\n\n\n

Extensions are upgraded entirely independently from your PostgreSQL cluster.<\/strong><\/p>\n\n\n\n

The code required to run an extension has to be added to your cluster, with each extension then ‘installed’ to a database – and they are database-specific. <\/p>\n\n\n\n

A practical example of how extension upgrades work across databases and clusters in PostgreSQL<\/h3>\n\n\n\n

To understand this further, let’s say – for example – you have two databases on your cluster. On one, you want to create and maintain geographical data. This means you\u2019re taking advantage of PostGIS (or a number of other extensions, depending on your needs.)<\/p>\n\n\n\n

The other one, meanwhile, is an OLAP (online analytical processing)<\/a> database<\/strong> – so you add pgColumnar<\/strong><\/a><\/code> (or Citus Columnar, or pg_mooncake<\/code>, or\u2026) to enable the use of columnstore<\/a> tables and indexes. Cool, right?<\/p>\n\n\n\n

Yes, but let\u2019s now pick on pgColumnar<\/code> in a completely fictitious way (and please let me emphasize: what I\u2019m about to say isn\u2019t true)…<\/p>\n\n\n\n

In this completely fake scenario, the people maintaining pgColumnar<\/code> are informed that there\u2019s a security hole in the product. They immediately get on it and supply an update. That’s great. However, you, my friend, had best be monitoring<\/a> which extensions you\u2019re using – and keeping an eye on them for just this kind of update.<\/p>\n\n\n\n

That’s because there’s currently no mechanism in PostgreSQL that will find and install these updates for you<\/strong> (outside of any third-part extension that may or may not have been created for this).<\/p>\n\n\n\n

What this means is simple: you could have a security vulnerability that you don\u2019t know about.<\/p>\n\n\n\n

\n
\n\n

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

SQL Server security vulnerabilities you weren’t aware of (full series)<\/strong><\/a><\/p>\n\n<\/div>\n<\/div> \n\n\n

Further, let\u2019s say you\u2019re on PostgreSQL 15. You decide that now\u2019s the time to upgrade to PostgreSQL 19<\/strong><\/a> or a later version, depending on when you’re reading this.<\/p>\n\n\n\n

In addition to all the processing, testing, and planning required to move from 15 to 19, you’ll need to determine which version of all your extensions is supported by 19. That\u2019s for every database, on every cluster, for every extension.<\/em><\/p>\n\n\n\n

See, a ton of work. “PostgreSQL extensions are horrible. No need to ever leave MySQL<\/strong><\/a>…”<\/em><\/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

Why this overhead isn’t unique to extensions<\/h3>\n\n\n\n

Ah, come on! We\u2019ve always had this problem. It\u2019s not new. Don\u2019t believe me? OK. Let me ask, how are you backing up your enterprise systems? Most likely with a third-party tool or a custom set of functions, right? <\/p>\n\n\n\n

And do you have to maintain those independently of your database? <\/p>\n\n\n\n

Yes, you do.<\/p>\n\n\n\n

How about the OS? Need to maintain that independently of the database? Again, yes. <\/p>\n\n\n\n

Security tools? Compliance? Deployment? Virus detection? I could keep going, but you get the point.<\/p>\n\n\n\n

Does this add some overhead and, let\u2019s be honest, risk<\/em> to our database clusters? Yes, it does. However, no more than all the other things I listed (and a million more). <\/p>\n\n\n\n

We work in a complex, ever-changing environment. Extensions are not the thing that broke the camel\u2019s back – especially true when you consider that the extensions make your camel rocket-powered<\/em>. <\/p>\n\n\n\n

Any addition to overhead is absolutely worth the price. We just need to know that going in.<\/p>\n\n\n\n

Are PostgreSQL extensions at risk of being abandoned?<\/h2>\n\n\n\n

Is it possible for an extension to simply be abandoned, no longer under development, completely and utterly unsupported<\/em>? Yes, it is.<\/p>\n\n\n\n

The overriding majority of extensions are created and maintained exactly the same way as PostgreSQL itself: through open-source development and distribution. The single largest concern around open-source is a lack of dedicated support and liability<\/strong>. <\/p>\n\n\n\n

Open-source projects get abandoned at a pretty high rate. Accurate numbers are tough to come by, but the shorter-lived the project, or the more niche and small it is, the higher that rate goes. Anyone saying this is not<\/em> a problem is probably trying to sell you something.<\/p>\n\n\n\n

After all, one of the largest and most popular extensions, pgBackRest<\/strong><\/code><\/a>, was nearly abandoned just recently.<\/p>\n\n\n\n

The pgBackRest<\/code> near-abandonment, explained<\/h3>\n\n\n\n

CrunchyData<\/a>, who had supported the project for 13 years, were purchased by Snowflake<\/a>, who didn\u2019t want to continue that support.<\/strong><\/p>\n\n\n\n

The result? Fast forward just a few days, and a nine-company coalition was formed to save it<\/a>.<\/strong><\/p>\n\n\n\n

On another note, when was the last time you used Skype? Or played any games on Flash? Or, to get more obscure (and expensive), remember the time the US government spent about $500 million on an eight-year project<\/strong><\/a> that is still three years from completion<\/em> (in theory) and has cost several billion dollars?<\/p>\n\n\n\n

The point is, commercial and closed-source software seem to suffer more than their share of abandonment as well. It’s not just a curse assigned to open-source.<\/p>\n\n\n\n

Why open-source can recover where closed-source can’t<\/em><\/h3>\n\n\n\n

I like to bring up the pgBackRest<\/code> story because it illustrates the most important part of this question. If an extension is used widely, is it likely to be abandoned? The answer is absolutely not<\/em>. <\/p>\n\n\n\n

When pgBackRest<\/code> hit the wall, there were immediately plans being made to fork the code or find other sources of support. The latter succeeded fast enough that the former wasn\u2019t necessary, but therein lies the power of open source: had<\/em> it been necessary, we could<\/em> have forked the code and kept it going.<\/p>\n\n\n\n

Another great example of this is the Hudson software<\/strong><\/a> project run by Sun. After Oracle purchased them, a fork was made of Hudson in 2009. That’s Jenkins<\/strong><\/a>, and it\u2019s still going strong today.<\/p>\n\n\n\n

While this is a risk, again, it\u2019s no different than risks we already run with both open-source and<\/em> commercial software.<\/p>\n\n\n\n

Which PostgreSQL extensions are supported in the cloud?<\/h2>\n\n\n\n

Can you run your ‘vital-to-the-business’ extension in the cloud? Well…let\u2019s narrow this down a little more. <\/p>\n\n\n\n

PaaS vs. VM vs. SBaaS: why support varies<\/h3>\n\n\n\n

Here, just saying ‘cloud’ is simply not adequate because, for example, the cloud includes Virtual Machines (VM)<\/strong><\/a>. Can you run your extension on a VM?<\/p>\n\n\n\n

Well, yes – you’re probably running it on a VM now, locally. <\/p>\n\n\n\n

What we mean when we say ‘cloud’, however, is more the platform-as-a-service (PaaS)<\/strong><\/a> offerings of EnterpriseDB, Google, Azure, and AWS. (And, over on the database-as-a-service (DBaaS)<\/strong><\/a> side, we’re limited in what extensions we can actually run.)<\/p>\n\n\n\n

All the various PaaS offerings are forks of PostgreSQL, many (most?) of which have split compute and storage in order to optimize them. Further, each cloud platform is radically different under the covers than your local implementation of Linux Mint – regardless of what operating systems, VMs or containers they’re using to work their magic. <\/p>\n\n\n\n

They\u2019ve also built out all sorts of hardware and networking in order to supply the functionality that their PaaS offers. <\/p>\n\n\n\n

Combine all of that, and an extension that fundamentally requires access to the underlying OS and storage engine (like TimeScale) simply can\u2019t be added.*<\/p>\n\n\n\n

Of course, Tiger Data does have a fork of their own<\/strong><\/a> for PostgreSQL, with which you can pay to run TimeScale on the cloud vendor of your choice.<\/p>\n\n\n\n

The answer here is honestly more complex. In this case, it has nothing to do with the popularity or support of the extension. As stated, it\u2019s dependent on how the cloud vendor\u2019s systems operate. That alone may or may not limit your ability to put your PostgreSQL on the cloud. <\/p>\n\n\n\n

However, as established, there are alternatives. You can always revert back to running a VM or use a service like Tiger Cloud. <\/p>\n\n\n\n

What extensions are supported across all major cloud vendors?<\/h3>\n\n\n\n

Of the roughly 575 extensions listed on the PostgreSQL Extension Encyclopedia<\/strong><\/a> (Pigsty, *snicker*<\/em>), only around 15% have cloud vendor support.<\/p>\n\n\n\n

(I’m using AI to generate these counts, so take it as you will).<\/em><\/p>\n\n\n\n

On that 15%, the extensions supported by all the major cloud vendors include:<\/p>\n\n\n

\n