Well, Percona TDE was leading to the queries being very inefficient / slow after upgrading to pgsql 17. Explain analyze shows that query planning time shoots up crazily. A decision was taken to go back to pgsql 12, which worked out fine as there was no incompatibility. I restored from the binary dump with the -j option, as our database is huge. I completely agree that downgrade is not a good option but a pragmatic one under the circumstances.
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).
On Mon, Sep 29, 2025 at 5:10 AM Merlin Moncure <mmoncure@gmail.com> wrote:
I have a strange requirement to downgrade from pgsql 17 to pgsql 12. This is because we found in production certain incompatibilities between both versions for our database. It should have been caught in testing but was not.
Agree with others that snap downgrade is not necessarily a good choice here. Either way, if I were in your shoes, I'd be loading a plain text dump, maybe with some light massaging to strip out some compatibility issues.
Can you let us know what the hang up is? Version upgrades these days are usually pretty painless except for some performance issues, unless you have some unusual situations, for example, exotic extensions.
