Atlassian migrated 4 million Postgres databases to shrink AWS bill Australian collaborationware company Atlassian has migrated the four million Postgres databases that back its customers’ Jira implementations to Amazon Web Services’ Aurora. Atlassian’s principal site reliability engineer Pat Rubis last week revealed the migration in a post that explains the company runs one database for each …
We sought comment from JPMorgan Chase but did not receive a response, so cannot report why the financial services organization wants to bin its custom domains.
Two reasons: 1) cost and 2) having to sell BofAisBetterThan.chase to Bank of America.
Speaking of which, When will the public finally be allowed to buy .google domains, even though its now owned by Squarespace, which violates the condictions under which the TLD was created.
> Speaking of which, When will the public finally be allowed to buy .google domains, even though its now owned by Squarespace, which violates the condictions under which the TLD was created.
Squarespace bought a product called "Google Domains", not the .google TLD. That (and others) are still run by Google Registry (https://www.registry.google/). It's more of a wholesale / retail agreement
It does sound like they’ve done “close down one instance of Postgress and start up another pointed at the same db.
I guess that keeping the service up whilst doing this could be tricky?
Also, watch Amazon change the pricing structure underneath them. Atlassian is saying “we’re making more money”. It’s only a matter of time before Bezos says that some of that is going to go into his pockets.
This post has been deleted by its author
Bezos is in sat at his desk in his huge island lair with his white cat. A red light lights up in the control panel on his desk.
Bezos allows himself a smirk and presses a button on the interphone. "Atlassian locked themselves in more, proceed immediately to project Boil The Frog".
Actually, I'm not sure if Amazon will want to change anything: the premise of "cloud" is magic scalability, i.e. paying extra for some notional hardware because you might use it. If you can switch to another project that makes more reliable use of resources, then they've got more to sell to the next chump.
However, for a company of the size of Atlassian you'd have thought they might want to own their infrastructure for the same reasons, just like StackOverflow did.
However, for a company of the size of Atlassian you'd have thought they might want to own their infrastructure for the same reasons, just like StackOverflow did.
The irony would be too rich for Atlassian to swallow: moving their data from the cloud to on-prem, just after finishing screwingmigrating their customers from on-premise to cloud-hosted as the only option for the Confluence and Jira.
“Although the path was long and technically challenging, we achieved our ambitious cost-saving target and improved our reliability and performance in doing so,” he concluded.
Hey u just wasted all that time and energy to put all your eggs in one basket and become AWS's bitch
Tap on back for the money saved from equally foolhardy nincampoops
Mulling on this throughout the day, I've developed the thought further.
Suppose AWS's devs did use Atlassian, and considered its "vital" to their work. If Atlassian plonking their tool suite wholesale on to AWS got thought about, AWS's devs should by now be thinking, "We've got to find an alternative". So AWS sets its software dev teams building or improving an alternative. The latter is more likely, you always want an easy start, and it's probably OSS.
So AWS works on it, produces an OSS equivalent of Atlassian's tools and keeps it OSS, and Atlassian's market evaporates all of a sudden.
At the same time, AWS should recognise that destroying the market for one of its key customers is not good for its own business. Atlassian goes bust, that's cloud rental income lost.
So is there some sort of tricky issue here for AWS devs (and devs on other clouds too)? Sure, there's a point where if a cloud operator doesn't trust its own cloud services then why should we. On the other hand, with a lot of current wisdom being that it's good to keep at least some stuff on-prem for "in case", how does a cloud operator get some on-prem resources of its own. Or rather, as a cloud operator is all on-prem, from where do they get some independent resiliency? Another cloud operator?!
> So AWS works on it, produces an OSS equivalent of Atlassian's tools and keeps it OSS, and Atlassian's market evaporates all of a sudden.
Amazon’s model would be to take the open source version of Jira and enhance it into an AWS service and because they are not selling the software, not make either the software or the updates available to anyone.
This is a fun problem. When I was at Google, supporting Hangouts, all of the other SRE teams used Hangouts for coordination during outages. WE used a private IRC channel.
Then there was the pager storm we had that took PagerDuty down. Among other things, we sent an SRE team over to improve their posture. I have no idea if they were charged for that.
Of course, a number of years ago, S3 had an outage--and it turned out that the golden configs for S3 were stored...in S3.
Given what I know about outages at Amazon, it would seem that doing the full SRE redundancy using us-east-2, us-west-1, and us-west-2 would be fine for a ticketing system. IF they are using a vendor that is also a customer, they should insist on a slightly custom deployment to achieve this.
Probably a good idea to note that the image in TFA is some sort of photoshopped composite ... the Earth and Moon are not in that relative size and distance. The linked Chinese site gives a 404 on those atm but phys.org has the separate originals:
https://phys.org/news/2025-07-tianwen-probe-captures-earth-images.html
According to Tom's:
No reason was given for the delay, but multiple sources indicate that it occurred due to a lack of demand. It was initially planned for the Taylor Fab to produce chips for the 4nm process node, but this has since been upgraded to 2nm, to compete with TSMC and Intel.
A supply chain executive told the publication that there is little demand for the originally planned 4nm process node at the site. "Local demand for chips isn't particularly strong, and the process nodes Samsung planned several years ago no longer meet with current customer needs," the executive said to Nikkei Asia. "However, overhauling the plant would be a major and costly undertaking, so the company is adopting a wait-and-see approach for now." Although it has already declared its intention to upgrade the site to manufacture the 2nm process node, that is a resource-intensive task in terms of time, effort, and money.
This is in stark contrast to TSMC, which now manufactures the 4nm process node at Fab 21 in Arizona for U.S.-based customers like Apple, AMD, Broadcom, Nvidia, and Qualcomm. And, despite being priced higher than chips made in other sites outside North America, its capacity is already sold out through 2027.
"Atlassian migrated 4 million Postgres databases"
For the DBA's as nobody ever thanks them enough - Thank you! As an Atlassian customer with a lot of stuff on JIRA and Confluence - the database move went well as we didn't suffer any outages or anything. I know this well as we're migrating stuff from one place to another and having to plan it really carefully. The IT team never get thanked...
I expect none of the databases were particularly large - would not be surprised if all are sub 250GB.
Also all should be using the standard schemas, so limited amount of variation across the estate.
Hence in some respect this process would the same as a product update of an on-prem instance. So yes I would expect it just work, although given its cloud, the risk was AWS glitching.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
