Beyond Migration: Using Database Migration Service for disk shrinking

When database engineers hear “database migration", they typically think of a one-time onboarding pathway—moving databases from on-premises environments to the cloud, or between different cloud providers. However, Google Cloud's Database Migration Service (DMS) supports Cloud SQL for SQL Server as a source. This opens up powerful, non-traditional operational patterns for SQL Server customers within Google Cloud. Because DMS enables continuous, low-downtime database replication between Cloud SQL instances—whether in the same project, across different projects, or across regions—it can serve as an everyday utility for day-two operations like storage management. In this post, we explore a compelling operational use case for DMS with Cloud SQL for SQL Server: executing disk shrinks with minimal application downtime. Why should I shrink my disk? In many production environments, database storage only moves in one direction: up. Features like Cloud SQL automatic storage increase are essential for preventing out-of-space outages during unexpected traffic spikes, large batch imports, index maintenance, or temporary staging loads. Similarly, over the lifecycle of an application, you might archive historical records, purge obsolete data, or drop unused indexes. When data is deleted, SQL Server marks the freed space inside your data files (.mdf, .ndf) as reusable for future writes; similarly, log truncation frees up space within transaction log files (.ldf). However, the database files themselves continue to hold their peak used space unless AUTO_SHRINK is configured — a setting that is generally not recommended in production due to severe index fragmentation and performance overhead. With a manual shrink operation on the database files using DBCC SHRINKFILE, you can release that unused space from SQL Server files back to the underlying disk. Even after shrinking the database files, though, the Cloud SQL persistent disk remains at its peak allocated capacity. If you do not expect your database to grow back into that allocated disk space anytime soon, you should consider shrinking the disk itself to reduce ongoing storage costs — especially in scenarios such as: After major data archiving or purging: You have permanently moved historical data to cold storage or BigQuery and your active dataset is now a fraction of its peak size. Recovering from one-time storage spikes: A runaway transaction, large data migration, or temporary staging load triggered storage auto-increase, leaving you paying for terabytes of provisioned disk capacity you no longer need. Post-refactoring or schema optimization: You have split tables out of a monolithic database into separate services, dropped large unused indexes, or applied data compression. The query below allows you to inspect both the allocated capacity and available free space for each database file fo a database: code_block <ListValue: [StructValue([('code', "SELECT \r\n DB_NAME() AS [DatabaseName],\r\n name AS [LogicalName],\r\n type_desc AS [FileType],\r\n -- Allocated size on disk (converted from 8KB pages to MB)\r\n CAST(size / 128.0 AS DECIMAL(18, 2)) AS [AllocatedSize_MB], \r\n -- Actually used space inside the file\r\n CAST(FILEPROPERTY(name, 'SpaceUsed') / 128.0 AS DECIMAL(18, 2)) AS [UsedSpace_MB], \r\n -- Free space left in the allocated file\r\n CAST((size - FILEPROPERTY(name, 'SpaceUsed')) / 128.0 AS DECIMAL(18, 2)) AS [FreeSpace_MB], \r\n -- Percentage of allocated space that is used\r\n CAST((FILEPROPERTY(name, 'SpaceUsed') * 100.0) / size AS DECIMAL(18, 2)) AS [SpaceUsed_Percent]\r\nFROM sys.database_files;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7154373ed0>)])]> You can monitor the following key Cloud SQL metrics in Cloud Monitoring to identify whether your provisioned disk quota significantly exceeds actual disk usage, indicating an opportunity for disk shrinking: database/disk/bytes_used: Tracks the actual amount of disk space currently consumed by your database files and logs. database/disk/quota: Represents the total provisioned disk capacity allocated to your instance. Cloud SQL provides a built-in storage shrink feature to reclaim this unallocated disk space, which works well when your workload can tolerate a planned maintenance window. However, native disk shrinking requires instance downtime proportional to the total allocated disk size — which can mean hours of offline maintenance for multi-terabyte drives. If your production SLAs cannot accommodate extended downtime, Database Migration Service (DMS) offers a minimal-downtime alternative. By continuously replicating your databases to a newly provisioned Cloud SQL instance with a smaller, right-sized disk, you can reclaim unused storage while your application stays online — requiring only a brief cutover window. To understand why this approach keeps your cutover window so short, let's first look at how DMS replicates data between

Excerpt shown under the publisher's RSS terms · 176 words · full text and figures are on the publisher's site