Do I need to REINDEX after a major upgrade?

Not because of the major version itself. The upgrade tool carries indexes across without rebuilding them. What forces a rebuild is a change in the library that decides how text sorts, which usually arrives with the operating system rather than with the database. If that changed, every index on a text column may now be ordered by rules the server no longer agrees with.

The one that actually bites

Sort order for text is supplied by the platform, not by PostgreSQL, and it has changed in ways that reorder real strings. An index built under the old rules still contains the old order, and the server has no way to notice: lookups simply fail to find rows that are present, and a unique constraint can stop detecting duplicates. There is no error and no log line.

This is why an upgrade performed by moving to a new base image is the risky one, and an in-place upgrade on the same host frequently is not. The question to ask is not which database version you moved to but which platform image you moved onto, and whether the collation provider version recorded in the catalog matches what is installed now. The server does record that, and a mismatch is reported when you look for it.

Text indexes, unique constraints over text, partitions keyed on text and range-partitioned tables are all in scope. Numeric and timestamp indexes are not.

Doing it without a maintenance window

Rebuilding concurrently is supported and is the right default on a live system, at the cost of taking longer and of leaving invalid leftovers if it is interrupted, which is the same failure mode described in building an index concurrently. Rebuild the affected indexes rather than the whole database, and check afterwards that each one came back valid.

Two other post-upgrade items are worth separating from this one because they are often lumped together. Planner statistics were historically not carried over at all, so the first hours after an upgrade were spent planning against nothing until somebody ran an analyze; PostgreSQL 18 now preserves them, with extended statistics still excluded. And extensions are upgraded independently of the server, so a version-matched binary is not the same as an upgraded extension.

Both of those, and the order to do them in, are in upgrading Postgres and its extensions. If queries feel slower after the upgrade for reasons unconnected with sorting, the first thing to confirm is whether the plans changed shape, and what an index-only scan depends on is a common source of that surprise.