It's definitely possible, and can make a lot of sense -- MyRocks/RocksDB for MySQL seems like an interesting and well designed system to me. It is fairly natural to compare MyRocks to InnoDB, since they're both MySQL storage engines. That kind of comparison is usually far more useful than an abstract comparison that ignores the practicalities of concurrency control and recovery.
The fact that MyRocks doesn't use B+Trees seems like half the story. Less than half, even. The really important difference between MyRocks and InnoDB is that MyRocks uses log-structured storage (one LSM tree for everything), while InnoDB uses a traditional write-ahead log with checkpoints, and with logical UNDO. There are multiple dimensions to optimize here, not just a single dimension. Focusing only on time/speed is much too reductive. In fact, Facebook themselves have said that they didn't set out to improve performance as such by adopting MyRocks. The actual goal was price/performance, particularly better write amplification and space amplification.
Multiple databases in postgres fundamentally share the same underlying infrastructure (i.e., WAL), and so do not offer much in terms of scalability or blast-radius protection compared to putting all tables in the same database.
I'm surprised to see the Portal listed. We have one for letting the grandparents talk to the kids, and it is the most unreliable piece of technology I've owned. Constant connection issues and laggy UI.
So obviously I was embellishing the language, but the sentiment remains the same. I found this because I checked the RDS admin panel, which I rarely do. I didn't get an email. It was very alarming to discover and makes me anxious about what other forced upgrades I'll miss.
I appreciate the point of this, but I think forcing upgrades is absolutely the wrong way to do it. Scream at me all you want, but don't force my stack to mutate and potentially break services.
Easy to blame AWS, but as the post you linked said, Postgres 9.6 is no longer going to be receiving updates from 11 November.
What do you want AWS to do here? Keep running software that won't get security updates? That seems a bit wild to me.
Communication could have been better, but there is no universe in which a managed database provider should be expected to continue to maintain instances with discontinued versions of software.
> What do you want AWS to do here? Keep running software that won't get security updates? That seems a bit wild to me.
PostgreSQL is open source, so they could keep patching the old version with security fixes.
Or... they could keep using just the community-supplied free-of-charge version and pocket all the money from not maintaining security patches themselves.
They are providing easier maintenance and monitoring for open source DBs. You can always avoid RDS and install Postgres manually on EC2, if you so desire.
I'm not saying RDS couldn't be better, but I wouldn't expect them to maintain unsupported versions of 3rd party software.
I agree AWS should be contributing back to the open source projects and they are listed as a 'sponsor' (though not a major one) on the Postgres website.
But AWS should not have to take responsibility for providing indefinite updates to every version of every managed open source project it operates. The only way I could see this working would be if AWS charged the holdouts the cost of keeping them supported.
However, performing RDS Postgres upgrades is relatively quick and painless process. If a company doesn't have the capacity to do that every five years, then it shouldn't be running its own infrastructure.
> The only way I could see this working would be if AWS charged the holdouts the cost of keeping them supported.
That actually sounds like a great idea. They could charge more for use of older versions, so that people could calculate their tradeoffs, and migrate when they decide themselves.
At some point the alternatives are force-updating your DB or shutting it down. One of those at least has a chance of keeping your service online. I agree the lack of communication is pretty bad though.
Maybe relatively, but it was what was on-hand (in jail) and by itself it was more than interesting enough to get me to begin reading the series in order when I got the chance.
I find it pretty odd to speculate that they are experiencing a very specific failure mode of a particular database. Do you even know whether they use Postgres?
I know we're already in the weeds, but Malcolm Gladwell’s “Revisionist History” did an excellent episode on the stuck accelerator problem, basically showing it almost certainly didn't happen.
OP specifically pointed out that it's well documented. Every program makes tradeoffs, and I don't think anyone in this thread implied that because Postgres made this one it's unstable or bad.
The specific behavior of Postgres isn't the FUD, the FUD is the speculation that this is what brought down Roblox for multiple days. As others have mentioned, we don't even know if Roblox uses Postgres, and yet we're diving deep on how an edge case of Postgres brought down Roblox. It's the speculation that I think is FUD.
As a parent, it's hard to remember that ending a weekend "recharged" is a common experience.