- Industry: Post-acute care technology (home-care SaaS)
- Organization: A leading U.S. post-acute-care technology company whose home-care platform coordinates daily care at national scale
- Environment: Self-managed PostgreSQL on AWS EC2, migrating to Google Cloud on local NVMe storage
- Engagement: Proactive DBA managed services
- Services: Cloud-to-cloud migration, Data lifecycle engineering , Proactive audits, 24×7 incident response
| Metric | Before | After |
|---|---|---|
| Mail-activity log data living in PostgreSQL | 4.89 TB (3.37 TB + 1.52 TB) | 0 (offloaded to S3 and DynamoDB) |
| Database size after the mail-log offload | 11.7 TB | 6.81 TB |
| Fit against the new cloud's 9 TB local-NVMe ceiling | Over the limit | 8.2 TB proven in test; production cut over |
| 186 High and Emergency tickets resolved | 186 raised | 186 resolved |
Contact Us
Reach out! This is your best opportunity to build a partnership with a leader in Postgres and Open Source support.
The Client
The client's platform: home care for agencies across the United States. Every shift schedule, every caregiver clock-in, every visit note and message between an agency and a family lands in one PostgreSQL database. When that database is slow, a coordinator cannot see who is standing in a patient's kitchen this morning. When it is down, care stops being coordinated at national scale.
The Challenge
The client decided to move the platform from AWS to Google Cloud. The plan called for local NVMe storage, with one hard limit: the local disk array topped out at 9 TB. The production database was well past it.
You cannot lift-and-shift what you refuse to clean up. A database that has grown for a decade carries everything: mail logs nobody queries, indexes nobody uses, history nobody reads but everybody is afraid to delete. The migration deadline turned that comfortable clutter into a blocker. Either the database lost terabytes, or the platform stayed where it was.
The Solution
- Move the mail out. Two log tables held 3.37 TB and 1.52 TB including indexes, nearly 5 TB of message history inside a transactional database. The history went to S3, live traffic went to DynamoDB. The database size reduced from 11.7 TB to 6.81 TB in one weekend.
- Archive the history. Ahead of the cutover we built a retention program: copy the current year of high-churn tables into new lean tables and ship the older data to Redshift where the analytics team could still reach them.
- Drop the dead weight. We verified indexes across every stack, primary, read, worker, and reporting. Then we dropped them CONCURRENTLY and production never noticed.
- Tier the cold data. After the move, we kept the NVMe volume lean by relocating cold tables to slower, cheaper disk in planned phases, using pg_repack during low-traffic windows.
Proactive discipline paid off elsewhere. During a routine audit we found four-byte integer primary keys quietly running out. The worst was at 2,029,172,512 of a maximum 2,147,483,647, filling at 15 inserts per second. Ninety-one days to overflow on a table with two billion rows. We migrated the columns to eight-byte integers using live mirror tables, with no downtime, long before the deadline arrived.
The Results
The production database left AWS and landed on Google Cloud local NVMe. The cutover went to plan. The client's reliability team reported the site online and stable afterward, with no major database incident.
"Thank you for the successful production cutover this weekend. Our site has been online, stable, and without major incident." (Client)
Why it Matters
Every cloud migration plan starts with the destination and works backward to the data. The data usually loses. This engagement proves the reverse order works: decide what actually belongs in your transactional database, move the rest to storage built for it, and the migration you thought was impossible becomes a maintenance window.