A production-like dump, a separate PostgreSQL 19 beta instance, one evening plus machine time. That is the whole method, and it is the only thing a database beta is for: finding out where the new version changes the behavior of your application while the change is still a bug report and not your incident.
Restore the dump first. Data size matters. A plan that is fine on a thousand rows goes bad on fifty million.
Collect twenty or thirty queries that represent the application. The report page, the search, the dashboard, the nightly job. The fast ones teach nothing. Then on both versions:
EXPLAIN (ANALYZE, BUFFERS) SELECT ...
Diff the plans. Timings alone lie on a quiet test box. A changed join order or an index that stopped being used shows in the plan first and in production later.
Then run migrations from zero and the ORM test suite against the beta. Drivers and ORMs hold assumptions too, and theirs break quieter than yours.
The most likely result of the whole exercise: everything is fine. That is the result, and it is worth writing down. Keep the plans, keep the numbers. When GA comes in autumn, the upgrade decision is a diff against your own saved baseline. And if something did regress, you have months to rewrite a query or file a report, while the version is still beta and people are still listening.
Guessing is also a strategy. It is the one with the worst worst case. I used it for years, and it mostly worked, which is exactly how it keeps getting used.