Why Does Everyone Run Ancient Postgres Versions?

command, SQL/JSON constructors and identity functions, parallelized vacuuming of indexes…

But now, to look at the other side of the coin: Unless you either a) are really reaching the limits of Postgres performance and are looking for any possible improvements or b) particularly need some newly added functionality, Postgres 12 probably works fine for you already.

The cost of change

So that’s the first reason many Postgres users hesitate to upgrade: Postgres is already great as it is. But we’d be fooling ourselves if we didn’t also acknowledge how painful it can be to update major versions of Postgres, especially for large production databases.

Minor updates are fine, and they’re completely covered for you by many managed Postgres services like Neon——for example, by supporting logical replication—and we’re working on a one-click Postgres upgrade feature so you can upgrade with minimal downtime. Not only that, but with Neon you’ll upgrade within a branch to ensure things work, and then upgrade your production with the least amount of interruption as possible. (Keep an eye on 2025 roadmap).

Real upgrade stories

To put things into perspective, let’s look at two public stories of companies that performed Postgres upgrades, jumping multiple major versions while managing databases of considerable size in production: (from Postgres 9 to 13). These are big leaps that need to be made strategically.

Here’s what these companies had to do:

1. Assessment and planning. They evaluated their database sizes and workloads (Retool had a 4 TB database; Knock managed multiple databases). Objectives like minimizing downtime and upgrading before end-of-life were set. They chose their target Postgres versions and crafted detailed project timelines and risk assessments.


2. Set up replication. New database instances running the target Postgres versions were spun up and logical replication from the old to the new databases was established. Retool used , here are some other reasons:
   
   
   
   
   
   • You’ll eventually have to do it anyway. Postgres versions have a lifecycle, and support for each version eventually ends (5 years after its initial release).
   
   
   • It’s more difficult to jump many versions at once. The longer you wait to upgrade, the more versions you’ll have to leap over when you finally do. It’s best to jump as many versions as you can when you do upgrade but if you wait for 5 or more versions there will be many compatibility issues and breaking changes ahead.
   
   
   • Your app might fall behind. Newer versions of Postgres come with performance optimizations and new functionalities that can enhance your applications. By sticking with an older version, you might be missing out on improvements that could make your system faster and more efficient.
   
   
   • Compatibility. New frameworks, libraries, and tools might come out without compatibility for the older version of Postgres you might be working with. Updated APIs or extensions might not be backward compatible, preventing you from integrating certain tools or requiring complex workarounds.
   
   
   
   
   

   
   
   
   Check what you’re missing out on: Run pgversions.com
   

   
   
   

   Part of the lack of inspiration around upgrading comes from the hassle of manually comparing release notes between versions and figuring out how many improvements you’re missing. To make this easier, we’ve built a tool: inspires you to finally upgrade, the How to upgrade section in the report will point you toward the right docs for different providers.
   
   Do it (before it’s too late)

   
   
   

   If you’re running an older version of Postgres and thinking there’s plenty more time. We know it’s tempting to procrastinate, but don’t let technical debt haunt you. . Feel free to .

   Vollständiger Original-Bericht

   Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

   ↗ Original-Artikel auf dev.to lesen