# How to Move PostgreSQL to Secure Block Storage > URL: https://www.atlantic.net/cloud-platform/postgresql-block-storage-migration/ | Published: 2026-11-04 | Updated: 2026-10-30 | Author: Hitesh Jethva As your PostgreSQL database grows, storage capacity becomes a concern. Larger tables, indexes, transaction logs, and application workloads consume available disk space. When your PostgreSQL server approaches its storage limit, PostgreSQL block storage lets you expand capacity without replacing the existing cloud server. Moving database files to an attached volume requires planning. You need to evaluate storage performance, database dependencies, backup procedures, and expected downtime. An incomplete migration might cause data inconsistencies or application failures. [Atlantic.Net Secure Block Storage](https://www.atlantic.net/cloud-platform/block-storage/) offers expandable storage for cloud servers. This guide explains when to move PostgreSQL, how to prepare the database, the main migration stages, and the checks required to maintain performance and reliability. ## Why PostgreSQL Databases Outgrow Server Storage PostgreSQL storage requirements increase as applications process more records and transactions. A database initially deployed on a small cloud server might eventually consume most available disk space. Several factors contribute to database growth: - **Growing tables and indexes:** New records increase table sizes, while indexes require additional storage. - **Write-ahead logging (WAL):** PostgreSQL records database changes in WAL files to support transaction durability and crash recovery. - **Temporary files:** Complex SQL queries, sorting operations, and large joins sometimes require temporary disk space. - **Dead tuples and table bloat:** Updates and deletes leave outdated row versions until PostgreSQL reclaims reusable space. - **Database backups:** Local backups, CSV exports, and retained logs consume additional storage. - **Application growth:** More users, new features, and longer data retention periods increase storage requirements. PostgreSQL uses multiversion concurrency control (MVCC) to manage concurrent transactions. MVCC maintains different row versions, allowing read operations to proceed alongside many write operations. PostgreSQL also uses granular locking to manage transaction conflicts. The VACUUM process tracks dead tuples and makes space available for reuse within database pages. Standard VACUUM generally does not return most allocated table storage to the operating system. Monitor storage capacity before disk usage becomes critical. Check available filesystem space using: ``` df -h ``` Identify the PostgreSQL data directory: ``` SHOW data_directory; ``` Check directory size using the path returned above: ``` sudo du -sh /path/to/postgresql/data ``` Review individual database sizes: ``` SELECT datname, pg_size_pretty(pg_database_size(oid)) AS database_size FROM pg_database ORDER BY pg_database_size(oid) DESC; ``` Compare these values over several weeks to estimate future storage requirements. Storage planning should also address throughput, IOPS, and disk latency. Running out of disk space might interrupt INSERT operations, transaction logging, temporary queries, and application availability. ## When Should You Move PostgreSQL To Block Storage? Adding storage does not always require a database migration. The right approach depends on your infrastructure, performance requirements, and acceptable downtime. Consider four options: - **Expand the existing server disk:** Increase primary disk capacity when your cloud provider supports expansion. This approach often requires fewer PostgreSQL configuration changes. - **Attach a block storage volume:** Add a separate storage device for database files or selected tablespaces. - **Relocate the data directory:** Move the existing PostgreSQL cluster to the new filesystem while retaining the same database instance. - **Migrate to another database instance:** Transfer data between an old database and a new database running on another server or instance. The distinction matters. Moving PGDATA on the same server preserves the existing PostgreSQL cluster. You do not need to create a new DB, reload every table, or recreate the database schema. A migration between two databases involves additional considerations, including database versions, application connections, data synchronization, and cutover procedures. For businesses that need more disk capacity without changing their PostgreSQL server, relocating the existing data directory to attached block storage is one option. ## How PostgreSQL Block Storage Works PostgreSQL manages data through a structured, page-based storage architecture. The fundamental unit of PostgreSQL data storage is a page, typically 8 KB. Tables and indexes consist of fixed-size pages. Within ordinary heap tables, pages do not maintain rows in a specific logical order. Each page contains a header, a line pointer array, free space, and stored records. PostgreSQL identifies a physical row version using a Tuple ID (TID), which contains a page number and item position. The line pointer array identifies where individual records reside within a page. This fixed-page architecture supports predictable buffer allocation and data access. ### How PostgreSQL Handles Read And Write Operations PostgreSQL uses shared buffers to cache database pages in RAM. When a query requests data, PostgreSQL checks its cache before reading from the underlying filesystem. The operating system provides additional caching and handles block-level I/O. During a transaction, PostgreSQL modifies data pages in memory. The database engine records changes through Write-Ahead Logging before modified data pages reach permanent storage. WAL supports durability by letting PostgreSQL replay logged changes after a crash. Checkpoints coordinate flushing modified pages from memory to disk. PostgreSQL also supports large tables through multiple relation file segments. Multi-terabyte tables do not require a single multi-terabyte filesystem file. Although PostgreSQL normally uses 8 KB pages, individual operating system and physical storage I/O requests are not restricted to exactly 8 KB. ### Using Atlantic.Net Secure Block Storage Linux recognizes an attached block storage volume as a block device. Administrators prepare a filesystem, configure a mount point, and provide PostgreSQL with access to the storage location. [Atlantic.Net](http://Atlantic.Net) [Secure Block Storage](https://www.atlantic.net/cloud-platform/block-storage/) provides NVMe-based volumes for compatible cloud servers. Its published specifications include: - Volume sizes from 10 GB to 16 TB. - Encryption at rest. - An isolated storage network. - Up to 7,500 standard IOPS per volume. - Up to 300 MB/s standard throughput per volume. - Volume-level storage replication. These I/O figures represent published limits, not guaranteed application performance. Compare existing PostgreSQL I/O measurements with the storage specifications before provisioning a new volume. Block storage supports transactional workloads requiring low latency and substantial IOPS, subject to the service’s actual performance characteristics. Dedicated physical resources sometimes reduce noisy-neighbor contention. Attaching a cloud block storage volume does not automatically provide dedicated physical disks or eliminate contention. Proper storage provisioning, filesystem configuration, and PostgreSQL I/O settings influence transaction speed and recovery performance. ## What To Check Before Moving PostgreSQL To Block Storage A PostgreSQL storage migration requires preparation before modifying database files or server configuration. ### Review Current Storage Usage Start by identifying database size, available disk capacity, WAL usage, and expected growth. Check PostgreSQL storage paths: ``` SHOW data_directory; SHOW config_file; SHOW hba_file; ``` Review mounted storage devices: ``` lsblk -f ``` Check the PostgreSQL page size: ``` SHOW block_size; ``` Record these details in your migration documentation. Include the current directory path, filesystem type, available space, and relevant configuration files. ### Check PostgreSQL And Application Dependencies Review the existing PostgreSQL setup before moving database files. Important checks include: - PostgreSQL version and database service configuration. - Application connections, database users, and access controls. - Extensions, tablespaces, and foreign data wrappers. - Replication slots, WAL archiving, and standby servers. - Scheduled jobs and external services. - Filesystem ownership and security policies. Check the server version: ``` SHOW server_version; ``` PostgreSQL stores tablespace references as symbolic links inside PGDATA. Separate WAL directories might also use symbolic links. Copying these links does not transfer the external files they reference. Identify and account for every external storage location before migration. ### Verify Backups And Recovery Create a consistent backup before relocating the database. PostgreSQL supports several backup methods: - **pg_dump:** Creates a logical backup of an individual database. - **pg_dumpall:** Exports databases and cluster-wide objects, including roles. - **pg_basebackup:** Creates a physical backup of a PostgreSQL cluster. - **WAL archiving:** Supports point-in-time recovery when combined with a suitable base backup. For example, save a compressed logical backup using: ``` sudo -u postgres pg_dump -Fc mydatabase > mydatabase.backup ``` Replace mydatabase with your database name. Verify the backup by restoring a copy in a testing environment. A successful backup command does not prove recovery readiness. See Atlantic.Net’s [How to Backup and Restore a Database in PostgreSQL](https://www.atlantic.net/vps-hosting/how-to-backup-and-restore-database-in-postgresql/) for additional backup and recovery guidance. ### Define Downtime And Recovery Objectives Business requirements should determine the migration schedule. Define two recovery objectives: - **Recovery Time Objective (RTO):** The maximum acceptable period of database unavailability. - **Recovery Point Objective (RPO):** The maximum acceptable amount of recent data loss. Plan a maintenance window with enough time for final synchronization, database startup, application testing, and rollback. Preserve the original data directory until validation finishes. Remember, once the relocated PostgreSQL cluster accepts new production writes, the old database files become outdated. After that, returning to the original directory requires data reconciliation or recovery. A simple path change is no longer sufficient. ## Main Stages Of Moving PostgreSQL To Secure Block Storage The migration process involves preparing the new storage, transferring cluster files, updating the PostgreSQL configuration, and validating the database. ### Stage 1: Provision The Block Storage Volume Select a volume based on current database size, expected growth, and storage performance requirements. Attach the volume to your cloud server and identify the new device: ``` lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS ``` Verify the device name before formatting or modifying storage. Choosing the wrong device risks permanent data loss. ### Stage 2: Prepare The Filesystem And Mount Point Create a suitable filesystem, such as ext4 or XFS, on the new device. Mount the filesystem at the intended location, such as /mnt/postgresql-data. Verify the mount: ``` findmnt /mnt/postgresql-data ``` Identify the filesystem UUID: ``` sudo blkid ``` Configure persistent mounting through /etc/fstab using the correct UUID. Set appropriate ownership and permissions for the postgres operating system user. Configure service startup dependencies so PostgreSQL does not start without its required storage volume. ### Stage 3: Prepare PostgreSQL For Migration Verify recent backups and confirm your rollback procedure. Pause application traffic and scheduled processes that write to the database. Shut down PostgreSQL cleanly before completing the final filesystem synchronization. Identify PostgreSQL services using: ``` systemctl list-units --type=service 'postgresql*' ``` Service names and cluster management commands vary across Linux distributions. ### Stage 4: Transfer PostgreSQL Data Transfer the complete PostgreSQL data directory while preserving ownership, permissions, symbolic links, and relevant filesystem metadata. The rsync utility provides one migration option. For large databases, an initial copy while PostgreSQL runs reduces the amount of data remaining for the maintenance window. The initial copy alone is not consistent. After shutting down PostgreSQL, perform a final checksum-based synchronization. Use the following command to preview the final changes: ``` sudo rsync -aHAXn --checksum --delete --numeric-ids \ /path/to/old/PGDATA/ \ /path/to/new/PGDATA/ ``` The -n option performs a dry run without changing destination files. Review the proposed additions, changes, and deletions. After verifying both paths, filesystem metadata requirements, and that the PostgreSQL service is stopped, repeat the synchronization without -n. The –delete option removes destination files absent from the source. Incorrect paths or unintended deletion rules risk data loss. Do not treat an ordinary live filesystem copy as a consistent PostgreSQL physical backup. ### Stage 5: Update PostgreSQL Configuration Configure PostgreSQL to use the new data directory or mount the volume at the existing directory location. Review: - PostgreSQL data directory settings. - File ownership and directory permissions. - Service startup configuration. - SELinux or AppArmor policies where applicable. - External WAL and tablespace locations. - Persistent mount configuration. Keep the PostgreSQL version and cluster identity unchanged during a straightforward data directory relocation. ### Stage 6: Restart And Validate PostgreSQL Verify the destination filesystem is mounted before restarting PostgreSQL. Test local connectivity: ``` sudo -u postgres psql -c "SELECT current_database(), current_user;" ``` Check the active data directory: ``` sudo -u postgres psql -c "SHOW data_directory;" ``` Review PostgreSQL logs and validate application connectivity. Do not remove the original database directory until the migration passes all required checks. ## How To Minimize Downtime During PostgreSQL Migration Minimal downtime requires a controlled migration plan. Downtime depends on database size, storage transfer rates, application activity, and the synchronization method. Follow these practices: - Schedule migration during periods of reduced traffic. - Measure actual transfer speed before production migration. - Perform an initial data copy when appropriate. - Stop PostgreSQL before the final synchronization. - Verify permissions and filesystem mounting before restart. - Test application reconnection procedures. - Complete a trial migration in a development environment. Real-time data migration and replication offer other approaches when moving to a different PostgreSQL instance. PostgreSQL’s Publish-Subscribe feature supports logical replication between compatible instances. The publication defines replicated changes, while the subscription receives and applies them. Logical replication helps synchronize two databases during migration. It requires planning for schemas, sequences, replication lag, and cutover behavior. Physical streaming replication provides another option for maintaining a synchronized PostgreSQL standby. Synchronous replication supports database-level durability requirements, although synchronous database replication is separate from storage-level redundancy. For a same-server data directory move, these replication methods are generally unnecessary. ### When Are Database Migration Tools Relevant? Database migration tools matter when you change servers, database engines, or application architectures. For example: - **pgLoader:** Supports data loading from sources such as MySQL into PostgreSQL. - **Ora2Pg:** Focuses on Oracle-to-PostgreSQL migrations. - **Striim:** Supports streaming data and change capture. - **Fivetran:** Provides managed data pipelines. - **Flyway:** Manages database schema changes through version-controlled migration files. - **DevCycle:** Uses feature flags to control application behavior during deployment or migration. Vendor claims involving pgLoader transfer rates of 3 TB per hour, sub-second streaming latency, or trillion-record processing volumes should not determine your local storage migration plan. Such figures describe different workloads or remain unverified for your environment. Moving an existing PostgreSQL cluster to another volume does not require these tools, a new database schema, or CSV-based data loading. ## Checks To Perform After Moving PostgreSQL A successful PostgreSQL startup does not validate the migration. Test filesystem access, database operations, application connectivity, and storage performance. ### Verify PostgreSQL Service And Storage Confirm the database service remains active. Check the current data directory: ``` SHOW data_directory; ``` Verify the destination filesystem: ``` df -h ``` Confirm the mount point: ``` findmnt /mnt/postgresql-data ``` Inspect PostgreSQL logs for unexpected permission, recovery, or I/O errors. Verify the filesystem remains available following a controlled server reboot. ### Test Database Connections And Transactions Test connections using the actual application database, role, and network connection method. Local access as the Postgres administrator does not verify application authentication or remote connectivity. Check the following: - Applications connect with expected credentials. - Tables, indexes, and schemas remain accessible. - Critical queries return expected values. - Read and write operations complete successfully. - INSERT, UPDATE, and DELETE transactions behave correctly. - Scheduled jobs and external integrations work. - Selected row counts, or application checksums, match pre-migration results. PostgreSQL maintains transaction consistency through WAL and MVCC. Your application testing should confirm expected business behavior after the storage move. ### Monitor PostgreSQL I/O Performance Storage performance should be evaluated using measurements collected before and after migration. Use iostat to examine device activity: ``` iostat -xz 1 3 ``` Review PostgreSQL connections: ``` SELECT datname, state, count(*) AS connections FROM pg_stat_activity GROUP BY datname, state ORDER BY datname, state; ``` Check database-wide activity: ``` SELECT datname, xact_commit, xact_rollback, blks_read, blks_hit FROM pg_stat_database; ``` On supported PostgreSQL versions, pg_stat_io provides additional I/O statistics. Monitoring I/O activity helps identify storage-related bottlenecks before application performance deteriorates. Compare: - Read and write latency. - IOPS and throughput. - Query execution times. - Transaction completion rates. - Disk utilization and free capacity. Account for cache warm-up after PostgreSQL restarts. Short performance tests immediately after migration might not represent normal application behavior. ## Why Extra Block Storage Does Not Replace PostgreSQL Backups Additional block storage increases available capacity. Storage replication and RAID address selected hardware failure scenarios. Neither replaces independent PostgreSQL backups. Database data remains vulnerable to: - Accidental table deletion. - Incorrect SQL commands. - Application bugs and failed updates. - Compromised credentials. - Filesystem corruption. - Storage and server failures. RAID sometimes improves storage throughput, while replication provides redundancy. Replicated storage might also preserve unwanted changes across every replica. Maintain independent, off-server backups with defined retention periods. PostgreSQL supports point-in-time recovery using base backups and archived WAL files. WAL replay restores database changes to a selected recovery point when a complete archive history is available. Use restore testing to confirm recovery procedures meet business requirements. Storage snapshots require PostgreSQL-consistent procedures. When data, WAL, and tablespaces span separate volumes, recovery depends on consistent handling across those filesystems. Extra storage addresses capacity requirements. Backups and tested recovery procedures address data protection. ## Best Practices For Managing PostgreSQL On Block Storage Managing PostgreSQL on separate storage volumes requires ongoing monitoring and configuration control. Follow these practices: - **Monitor capacity:** Configure alerts before available filesystem space becomes critical. - **Review I/O performance:** Track latency, throughput, and IOPS during normal workloads. - **Maintain VACUUM:** Monitor dead tuples and table bloat to improve space reuse. - **Track WAL usage:** Investigate inactive replication slots and failed archiving operations. - **Verify backups:** Test database restoration and point-in-time recovery procedures. - **Check mounts:** Confirm storage volumes mount correctly following maintenance or reboot. - **Document changes:** Record storage paths, filesystem UUIDs, configuration details, and recovery procedures. - **Plan future expansion:** Review database growth before increasing application workloads. Separating PostgreSQL data and WAL volumes sometimes reduces I/O contention when each volume offers independent performance resources. Additional volumes increase operational overhead. Each volume requires appropriate monitoring, mount configuration, and recovery coordination. Test PostgreSQL performance before adopting separate WAL storage. Storage layout changes should follow measured application requirements, not assumptions about performance improvements. ## Final Thoughts Planning a PostgreSQL block storage move begins with reviewing database growth, server capacity, application dependencies, and storage performance. Expanding the existing disk might be sufficient for smaller workloads. Moving PostgreSQL data to an attached Secure Block Storage volume offers another approach when independent storage management is required. Before migration, verify backups, define downtime and recovery objectives, prepare the filesystem, and establish rollback procedures. During migration, preserve cluster consistency and confirm every required data file reaches the new location. After migration, validate application connections, transactions, filesystem mounting, and I/O performance. Continue monitoring disk usage and database health as workloads grow. A successful PostgreSQL storage migration depends on accurate capacity planning, controlled data transfer, reliable recovery procedures, and ongoing operational monitoring.