Re: Downgrade pgsql 17 to pgsql 12 question

On Tue, Sep 30, 2025 at 3:47 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> On Tue, 2025-09-30 at 13:53 +0530, Ashish Mukherjee wrote:
> > Now the consideration is to use some other encryption option for the
> > database which will work fine on pgsql 17. Cybertec's technology is
> > one route, the other is EDB. I am happy to hear experiences of folks
> > here with pgsql encryption options for v17 on large databases
> > (2.5T in our case).
>
> I will refrain from making a recommendation, but you should know that
> data-at-rest encryption will always incur a certain performance penalty.
>
> Whatever solution you choose, you should run performance tests.
>

Yeah. This applies to database upgrades in general.

The lists have quite a bit of, I upgraded, and "query X that drives my
platform now is 100x slower". I don't think this suggests that postgres is
getting worse; foundationally, it's mostly getting faster, but simply that
the planner changes how it responds to certain conditions. Over time, I've
learned some painful lessons and try to write SQL that is less risky from a
performance standpoint.

Developers tend to optimize into fragile planner behaviors chasing
performance, sometimes without realizing it. These kinds of issues are
almost always very fixable assuming you can modify the SQL or the thing
writing the SQL. The takeaway here is: test/verify before making major
upgrades, and bake in some recalibration time. Adding encryption or other
major features strongly reinforces that need.

merlin