Atlassian

Migrating the Jira Database Platform to AWS Aurora

Atlassian migrated about four million Jira databases from RDS Postgres to Aurora, balancing reliability, downtime and cost.

More on running PostgreSQL on AWS RDS, where Figma and Notion partitioned and sharded instead of moving.

Published
2025-07-02
Scale
4 million databases
Techniques
database migration multi-tenancy cost optimization
Stack
PostgreSQL AWS Aurora AWS RDS

Try this stack yourself

  • Railway · Deploy something like this on Railway: spin up PostgreSQL plus your app in a few clicks. New accounts get $20 in credit (applied when you pick a paid plan).
    Railway isn't part of Atlassian's setup in this story. It's just an easy place to try the same building blocks.

Some links above are affiliate links: if you sign up, How They Scaled may earn a commission at no extra cost to you. We only list tools that fit the stack in the story.

See also

Aurora vs RDS PostgresClickHouse vs Postgres for analytics at scalePostgreSQL vs MySQL at scale

The best scaling write-ups, weekly

One email a week. No spam.

Open subscribe page

Related stories

Figma · 2024

How Figma's Databases Team Lived to Tell the Scale

Figma's nine-month effort to horizontally shard its Postgres stack using a custom query proxy and logical sharding before physical splits.

horizontal shardingquery proxyonline migrationPostgreSQLAWS RDS
Figma · 2023

The growing pains of database architecture

How Figma moved from one Postgres instance to multiple databases by vertically partitioning table groups.

vertical partitioningread replicasconnection poolingPostgreSQLAWS RDS
Notion · 2021

Herding elephants: Lessons learned from sharding Postgres at Notion

Notion split its Postgres monolith into a fleet of logical shards keyed by workspace, using double-writes and backfills to migrate.

horizontal shardingonline migrationdouble writesPostgreSQLAWS RDS
PlanetScale · 2026

Designing a planned switchover for minimum disruption

When a Neki shard's primary has to step aside for a pod replacement, kernel upgrade or cell move, PlanetScale does a planned switchover instead of stopping Postgres the way Patroni does, so a failed switchover can quickly fall back to the old primary. Admin, Neki's control plane, first validates shard state, the target replica, logical failover slots and Postgres settings. Routers then proactively buffer primary-bound queries, the primary defaults new transactions to read-only, and the other replicas are disconnected to pin a final WAL position the target must replay. If the target can't catch up before a deadline, a config reload makes the old primary writable again. Buffered queries are replanned against the new primary, so apps see added latency instead of errors, and every acknowledged commit is on the target when it is promoted.

one primary and multiple replicas per shardsynchronous replication ANY 1 across eligible replicasplanned switchoverquery bufferingsynchronous replicationPostgreSQLNekiKubernetes