2026 PostgreSQL 14 Upgrade: How Much Disk Space Should pg_upgrade Reserve?

The upgrade plan is ready, but the target volume’s free space is still uncertain.

Fastest answer: There is no reliable fixed multiplier for PostgreSQL 14 pg_upgrade. Inventory the data directory, tablespaces, WAL locations and destination paths, then estimate space separately for copy, link or a supported clone. If the chosen method leaves no safe rollback path, verify an off-machine backup and rehearse the upgrade in an isolated target environment before scheduling production cutover.

This guide is for DBAs maintaining PostgreSQL 14 production systems who need to assess upgrade storage before the support deadline. It also helps SaaS technical leads plan database capacity and engineers understand how migration mode changes disk use and rollback options.

Last updated November 4, 2026. The support date and pg_upgrade behavior below were checked against the PostgreSQL version support policy and the PostgreSQL 18 pg_upgrade documentation.

Start by mapping every location that uses storage

Do not treat the database’s logical size as a complete disk estimate. A logical size reported by a query does not necessarily describe all filesystem space that an upgrade must preserve, copy or keep available. PostgreSQL can store tablespaces outside the main data directory, and WAL can be placed on a different filesystem. The PostgreSQL file layout documentation and tablespace documentation explain why these locations need separate accounting.

PostgreSQL 14’s listed support end date is November 12, 2026, according to the official version support page. That date makes it sensible to schedule the work, but it does not make a rushed migration safer. Capacity checks, a recoverable backup and a tested cutover plan still come first.

Start with a location inventory:

• Record the active cluster’s data directory and its filesystem.
• List every tablespace, its actual path and the filesystem that contains it.
• Locate WAL and record whether it shares a filesystem with the data directory.
• Identify the new cluster’s data directory and tablespace destinations.
• Record filesystem free space at each source and destination, not just the free space reported for the server as a whole.
• Include space needed for the backup, logs, temporary files and any synchronization step in the migration plan.

Useful first-pass commands include du -sh "$PGDATA" to inspect the apparent size of the main data directory and df -B1 "$PGDATA" to check free bytes on its filesystem. Repeat the filesystem check for every tablespace, WAL location and destination. These commands are inventory aids, not a capacity guarantee: they do not replace a review of the selected migration method or account automatically for files stored elsewhere.

Does pg_upgrade --check verify that the disks have enough capacity? No capacity estimate should rely on that check alone. --check is useful for detecting upgrade compatibility and configuration problems, but teams must inspect the actual paths, free space and migration mode separately. Review the official pg_upgrade options and check-mode behavior before treating a successful check as evidence that storage is sufficient.

Choose the migration mode for the space and rollback you need

The same source cluster can have very different storage requirements depending on how the new cluster is created. A mode that reduces copying may also reduce the options available for returning to the old cluster. Decide which risk is acceptable before allocating disk or booking a production window.

Use link only when its constraints and rollback risk are acceptable

In link mode, pg_upgrade uses hard links to reuse data files rather than making a complete independent copy of each file. This can reduce the additional space needed for database files, but it is not a general-purpose way to make an undersized filesystem safe.

The old and new cluster data directories must meet the filesystem conditions required for hard links. Check the documentation for the target PostgreSQL version, including the PostgreSQL 17 pg_upgrade guide or the PostgreSQL 18 guide, rather than assuming that different directories can always share files. The required paths and filesystem arrangement matter.

The rollback tradeoff is significant. After the new cluster has been started, the old cluster should not be treated as an untouched, independently usable copy. Link mode saves copying space by sharing files; it does not create a second clean cluster that can be switched back to without checking the documented restrictions. Before choosing it, make sure the external backup is recoverable and that the team understands the recovery steps if validation fails.

Can link mode save space without affecting rollback? It can reduce the extra space used for copied database files, but it changes the rollback assumptions. If the old cluster must remain available as a straightforward fallback, prefer an approach that preserves an independent old copy, or use a separately tested target environment.

Prefer copy when keeping the old cluster intact matters more

The default copy approach creates new copies of the required database files for the new cluster. Budget for the old cluster to remain in place while the new cluster is created. Account for the files on each tablespace filesystem as well as the main data directory; a large tablespace on a separate mount can be the limiting factor even when the main volume appears to have room.

Copy is easier to reason about when the upgrade plan depends on retaining the old cluster for comparison or rollback, because it avoids the shared-file behavior of link mode. It still does not guarantee that rollback will work automatically. Application changes, writes after cutover, configuration changes and the recovery procedure all affect whether the old cluster is a safe fallback.

A successful copy also requires free space on the filesystems that receive the new files. Do not add the size of the entire server’s storage and assume that it is interchangeable: free space on one mount does not help if the destination path for a tablespace is on another full filesystem.

Consider clone only when the filesystem supports it

Clone mode can create a copy using filesystem-level copy-on-write features, allowing the old cluster to remain available without immediately duplicating all underlying data blocks. That behavior depends on support from the operating system and filesystem. It is not a universal substitute for either copy or link.

Confirm that the target PostgreSQL documentation describes clone support for the environment in use, and test the actual filesystems and mount arrangement in a staging migration. Do not assume that a filesystem supports the required operation merely because it is mounted on a system that supports other forms of snapshots or copy-on-write.

Is copy or link the safer choice for a major-version upgrade? Choose copy when preserving an independent old cluster is a priority and the destination has room for the copied files. Consider link only when its filesystem requirements are met, space is constrained, and the team accepts its rollback limitations. Consider clone only after confirming and testing support on the actual platform. The safer choice is the mode that meets the storage budget and the recovery plan together.

Follow a capacity workflow before production cutover

Use this sequence to turn a rough estimate into a migration decision. Run it in a staging environment with representative data and the same filesystem layout wherever possible.

1. Inventory the live cluster. Record the data directory, every tablespace, WAL location and the filesystem used by each. Note any symlinks or mounts that would make a simple directory-size check incomplete.
2. Measure actual use and free space. Check used and available bytes on each relevant filesystem. Do not count unused capacity on a different mount as available destination space.
3. Choose the intended target layout. Decide where the new data directory and tablespaces will live. If the target is a separate environment, record its capacity independently from the source.
4. Select a migration mode. Compare the requirements and limitations documented for copy, link or clone on the target PostgreSQL version. Include temporary files and WAL growth required by your own procedure.
5. Build a location-by-location estimate. For each filesystem, list existing files that must remain, files that will be created, temporary working space and free space after the operation. Keep source retention separate from target capacity.
6. Run the supported checks and a staging migration. Use pg_upgrade --check for its documented checks, then execute the migration process in isolation. Observe the actual space consumed at every relevant path; do not import another team’s estimate as a guarantee.
7. Test recovery and cutover. Restore the off-machine backup, verify application connection changes and define when writes can resume. If the backup cannot be restored or the rollback decision is unclear, postpone the production switch.

Keep a record of the measured staging footprint and the exact filesystem layout. That gives the team a traceable estimate for the production plan instead of a single unqualified “database size” number.

Keep backup, replication and rollback as separate safeguards

Three storage needs are often collapsed into one: the space for the new cluster, the space to retain the old cluster and the storage needed for a restorable backup. They solve different problems. A copied old cluster may help with some rollback scenarios, but it is not an off-machine backup. A backup file on the same server is not protected from loss of that server or its storage.

For a filesystem-level backup, follow PostgreSQL’s requirements for a consistent copy; the official file-system backup documentation explains the conditions. For other backup methods, use the relevant procedure and verify that it can restore the required database state. A backup that has never been restored is an assumption, not a validated recovery option.

Before approving cutover, check:

• [ ] Data directory, tablespaces, WAL and destination paths are recorded with their filesystems.
• [ ] Free space is measured separately for every filesystem used by the migration.
• [ ] The selected mode is supported by the target version and filesystem layout.
• [ ] Required room for source retention, target files and temporary work is included.
• [ ] An off-machine backup exists and a restore has been tested.
• [ ] The team has written down the cutover sequence and the conditions for stopping or rolling back.
• [ ] Any replication or software RAID design is treated as a separate protection layer, not as a replacement for backup.

If the plan uses replication or software RAID, verify its failure and recovery behavior independently. Neither guarantees recovery from accidental deletion, logical corruption or a bad migration. A dedicated physical server does not make database data immune to loss.

Compare the storage scenarios before changing the server plan

The first table compares the decision that affects extra disk use and the old cluster’s status. The second is a planning worksheet: fill it with measurements from the actual environment rather than estimates borrowed from another deployment.

Match the measured requirement to the server plan

After the inventory and staging run, compare the capacity needed at each destination with the actual options in the server product table. This should be a capacity and operational-risk check, not a promise that moving to a different machine will make the upgrade faster. No performance or migration-time conclusion follows from disk capacity alone.

If the current environment cannot provide the required target space, compare the risks of changing the migration mode with the costs and risks of arranging a suitable independent target. Do not select link solely because the copy estimate does not fit; first confirm the link constraints and verify that the backup can restore. If there is no safe way to preserve or recover the data, defer production cutover until the storage and recovery plan are adequate.

For budget comparisons, include the full period for which the source and target must coexist, plus any backup storage and migration work. XFP Cloud billing information can be checked alongside the team’s measured requirements; do not infer an upgrade budget from a server’s headline capacity alone. Keep data handling and backup responsibilities clear as part of that review, using the applicable data-handling information.

A shared cloud instance may be easy to provision, but it can leave less control over the storage layout, resource consistency and the long-term cost of retaining separate source and target capacity. A managed database can reduce operational work, but its storage and migration options still need to match the workload and recovery requirements. If the database needs dedicated compute and a storage layout chosen for a sustained migration and production workload, compare those requirements with the current AMD physical-server options from XFP Cloud. Check the actual product table before making a commitment; where capacity, backup restoration or rollback remains unverified, keep the production cutover unscheduled.