Why migrate from PostgreSQL? In Squarespace's own words:
[PostgreSQL] doesn’t scale horizontally – at least not completely – and for several of our use cases, we had already pushed vertical scaling to its limits. At the same time, as our systems and ambitions grew, scheduling downtime for maintenance – or preparing for disaster recovery and other unplanned outages – started to impose a tax in the form of developer toil and business impact, both of which had become increasingly unacceptable.
And, why migrate to CockroachDB? Again, in their own words:
CockroachDB (CRDB) stood out. It speaks Postgres (mostly), seamlessly scales both reads and writes horizontally across low-cost machines, and promises to keep our data alive and healthy regardless of which node decides to call it a day. Most importantly, its compatibility with our existing architecture gave us the confidence we needed to adopt it.
Migrations are hard. My advice to people with Greenfield projects is to think ahead; if their ambition demands more scale than a vertically scaled Postres instance can provide... avoid the migration and just start with distributed SQL.
This short article from May '25 on Squarespace's blog discusses, in great detail, the approach and complexity of their migration from PostgreSQL to CockroachDB using change data capture (CDC):
Pravish Sood
While MOLT Fetch didn't meet all their requirements at the time, I wonder if that's changed. In the time since Squarespace migrated, MOLT, our migration toolkit, has matured quite a bit, along with adding support for Oracle migrations. Regardless, migrations are often complicated, and I really enjoy when customers share their stories so please have a look at the original post.
Spin up your first CockroachDB Cloud cluster in minutes. Start with $400 in free credits.
