This stuff isn't magic, everything is based on server load, but because it's the one database that's where the bottleneck happens.
That's probably
not exactly where the bottleneck is, on a technical level. Databases are generally designed around fast data updates. Even on cheap hardware any standard database server should be able to run thousands of updates a second. There will be nowhere near that many carrier jumps taking place - even one per second would require over 1000 players all logged in jumping their carriers at max rate (or twice as many at half-rate, etc).
Similarly we do hundreds of other operations with our CMDRs every day which involve updating a database - scan a planet, shoot an NPC down, trade some goods - for which in normal circumstances we get near real-time responses. If you hand in a bounty you don't have to come back 15 minutes later to see the credit balance updates. Even at really busy times it'll spin for seconds rather than minutes to think about it. The number of non-carrier database transactions players are carrying out will be massively bigger than the number of carrier jumps.
The problem is more likely to be synchronisation across multiple databases. If you buy some trade goods from a market, then supply goes down for everyone else ... but it's not really crucial that they see the reduced supply immediately: if they happen to buy the "same" trade goods that you did, it's generally not a problem because there's plenty more on the market and exactly which ones you took doesn't matter much [1]. So you can buy from one market database, they can buy from another, the two can be reconciled later and the final supply number will be right eventually. If it takes three hours to do that final reconciliation, or if it's a really busy market and doesn't actually get cleaned up in full until the Thursday morning downtime, probably still no-one notices, so the reconciliation changes can be ultra-low priority compared with normal trade activity.
Carrier position is obviously one thing which really can't work this way: every player needs at least in theory to be able to agree on where every carrier is at any time. So the question isn't "how long will it take to update one primary database" but "how long will it take for every other secondary database and running game client to definitely be updated with that information". Presumably the answer is normally "15 minutes" as some trade off between speed of updates and not having every game client asking the servers every second "have any carriers relevant to this system moved this second?" and mostly being told "no".
This is also a situation where
more hamsters is not necessarily better for carrier jumps specifically. If there are more people logged in, and therefore more servers running to support their normal activity, that means more replication needed for carrier jumps. So it potentially ends up being a trade-off between "carrier jumps take longer" and "almost everything else takes longer". And there's a lot more "everything else" to complain about.
Consistency of data across multiple datasets is one of the really hard programming problems, and the faster the data needs to be consistent the harder it gets to avoid some sort of unpleasant trade-off. Given that station data was originally "requires a client patch to update" [2] and then "requires a Thursday reset to update", getting it down to 15 minutes is impressive.
[1] There
are odd effects when the supply gets really low, though, which make this effect noticeable. But you have to really be watching out for it - you'd virtually never see it in normal play.
[2] "Thank you for all your carrier repositioning requests; they're in the queue and ready to be included in Update 18"
