Question: Vacuum, bloat and wraparound
Does VACUUM block other queries?
Answered in the first paragraph. Last updated .
No. A plain vacuum runs alongside ordinary reading and writing, and the documentation says so directly: it takes no exclusive lock on the table. That is the whole design. What it does conflict with is a small set of other operations, and there is one phase at the very end, when it hands empty space at the end of the file back, that needs the strongest lock the server has.
The phase at the end that people trip over
After the main work, a vacuum will try to shorten the file if the last pages have become empty. Shortening a file is not something that can happen while anybody is looking at it, so that step takes an access exclusive lock. It is normally over in moments, and on a table where even moments are unacceptable the behaviour can be switched off per table: the option exists precisely so the truncation, and the lock it requires, can be declined.
Declining it has a price. The empty pages stay, so the file keeps its size and the space is only reusable by that table. Most clusters should leave the default alone and know that this is what an occasional brief stall on a large table was.
What it genuinely conflicts with
The lock a vacuum holds for the rest of its run is a middle-strength one. It does not conflict with reads or with writes, and it does conflict with itself, with schema changes, and with an index build that is not the concurrent form. So the pairs that actually collide are a migration and a vacuum, or two vacuums on the same table, and in both cases the one that waits is usually the one you care about. Lock modes and what conflicts with what has the grid.
The practical consequence is a deployment rule rather than a vacuum setting. A schema change that arrives while a multi-hour vacuum is running on the same table will wait for it, and everything arriving behind the schema change will wait too. Set a lock timeout on the migration so it gives up instead of building a queue, and lock contention and blocking trees covers reading the queue once one exists.
One thing vacuum gives you that is worth the interruption: it marks pages as containing nothing that any transaction still needs to check, which is what makes an index-only scan possible at all. That bookkeeping is the visibility map. The full rewrite variant is a different command with a different answer, covered in does VACUUM FULL lock the table.