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.
