Last night I finished moving ShopSavvy’s main Postgres database off Google’s AlloyDB and onto a PostgreSQL server we run ourselves on DigitalOcean, on the same machine as the app. The database was a little under 1 TB. Services went down at 00:55 UTC and came back up at 01:00, talking to the new database.
\nI did it by myself over most of a week, and it went smoother than I expected. Here’s how it went.
\nThere’s no way to copy a terabyte in five minutes, so almost all of the work happens while the old database is still serving traffic. The plan had four big pieces:
\npg_dump and pg_restore.Only that last step is downtime. Before any of it, I made sure the database host and port came from environment variables everywhere, so switching servers meant editing config files, with no code changes and no deploys on cutover night.
\nThe cheapest data to move is data you don’t move. A few tables had years of rows we never read anymore: old scrape runs, click logs and history. I copied every row older than our retention window into its own table with CREATE TABLE AS, dumped each one, uploaded the dumps to object storage, checked them there and then deleted the rows.
One thing worth knowing if you ever do this: check for NULL in the column you’re filtering on. A WHERE time_created < ... clause quietly skips rows where time_created is null, and one table had 65.5 million of them. Adding OR time_created IS NULL and running a second pass picked them up.
All together that archived about 154 million rows into 21 GB of compressed dumps, and the biggest table went from 92.5 million rows to under a million.
\nThe new box got 64 GB of RAM, 8 CPUs and 1.2 TB of NVMe. AlloyDB is Postgres 14 underneath, so I installed PostgreSQL 14 to match and added the extensions the app uses: pgvector for product embeddings, pg_trgm, pg_stat_statements and hypopg. I tuned the basics for the machine (shared_buffers at 16 GB, effective_cache_size at 40 GB), set vm.swappiness to 1, turned off transparent huge pages, and only allowed port 5432 through the firewall from my own IP.
The snapshot copy was the long part. pg_dump wrote a directory format dump, 76 GB compressed across 123 files, in a little over four hours. pg_restore turned that back into 574 GB on the new server in about four hours and forty minutes, building 1,057 indexes with none invalid. The only errors were three expected ones about AlloyDB’s own extensions, which don’t exist outside AlloyDB.
A snapshot is out of date as soon as it’s taken, so the new server subscribes to the old one with Postgres’ built-in logical replication and receives every change as it happens. Getting AlloyDB to publish took a few steps:
\nalloydb.logical_decoding database flag in the console, which restarts the instance, and confirm wal_level is logical afterward.REPLICATION role to the user that owns the publication. AlloyDB doesn’t hand it out by default.FOR ALL TABLES also picks up AlloyDB’s internal pgsnap schema, and FOR TABLES IN SCHEMA public is Postgres 15 syntax, which a Postgres 14 server doesn’t understand.So the publication is a long CREATE PUBLICATION ... FOR TABLE with every table in the public schema, and the new server has a subscription pointed at it. You can watch it catch up from the subscriber side:
SELECT subname, received_lsn, latest_end_lsn\nFROM pg_stat_subscription;When those two numbers match, the new server has everything the old one has sent.
\nBefore calling it ready I ran nine smoke tests against the new database: row counts, product search, the offers join, the deals feed, saved items, price history, a pgvector similarity query across 1.16 million embeddings, and a check for invalid indexes.
\nWith replication caught up and the tests passing, the downtime part is short and very scripted:
\nreceived_lsn equals latest_end_lsn one last time.127.0.0.1.ANALYZE.Step five is the one people forget. Logical replication copies rows, but it doesn’t copy sequence values, so every serial column on the new server still thinks it’s at whatever number the restore left it at. The first insert after cutover would collide with an existing id. I reset all 85 of them, 72 owned by a column and 13 standalone ones. For a sequence owned by a column, that means setting it to the column’s current maximum:
SELECT setval('products_id_seq', (SELECT max(id) FROM products));At 01:00 everything came back up. The site returned 200 and 107 connections were open against the local database.
\nRunning Postgres yourself means doing the things a managed service did for you, so that same night I set up a daily backup to object storage (written to a temp name and renamed when it finishes, so a half-written backup never looks like a good one), ran VACUUM ANALYZE on the biggest tables, and added a small monitor that posts disk, memory, connection counts and cache hit ratio to Slack. AlloyDB is staying up for a few days as a fallback before I shut it down.
With the database on the same machine as the app, every query skips the network hop it used to make, and the connection pool went from 200 down to 30. It’s been a fun one.
","created_at":"2026-04-03T13:00:00.000Z","updated_at":"2026-04-03T13:00:00.000Z"}