The real divide here is not technological divide, it's a class divide.
I have mingled close enough with high net worth people to know they'll use 501c3-Signal's hosted service, Telegram, or even WhatsApp and other normie trash to reach an audience when doing so is convenient for them.
But amongst their legit peers and family they don't use any of that. Some of them use supported forks of the Signal software. Many of them use Matrix and grew up with XMPP so some of them use that too. SimpleX has made great strides here but there are more to be done.
These are not people who personally find computers interesting.
Maybe you'd think many of them are using iOS, macOS, or Windows, and they do have those for some things some of the time. But only some of the time.
FOSS' "free market" angle is very strong for clients of enough worth to fund skilled resources who can actively develop and maintain hardened systems suitable to defend the interests of estates, portfolio, larger family, and lives ultimately.
FOSS' "free market" angle enables for protection at a strata that no normie tier closed source OS will ever provide for. See Reproducible Builds and GNU Guix' Bootstrappable Builds for example.
"Bro, just trust us", isn't good enough. Not for people of responsibility. Not for people who love their own family.
Randomly "getting hacked" is not a thing along this strata of upper class.
Some not born into family with big money make a choice to pursue literacy.
In this decade, literacy in network protocols, cryptography, operating system, and userspace software is literacy. Lack of this is illiteracy.
Some live under the shadow of some harsh lesson learned by the family or some personal life lesson. Others didn't grow up in the West and aren't "blue pill" on the topic of government.
The East German Stasi, and that the Stasi's primary concern were "average people" with a little too much of an opinion, is still in living memory for a lot of people.
Others simply know for themselves what they are worth to themselves. Ultimately, sovereignty and dignity are their own spiritual choice. Some make that choice.
So again, it's a class issue.
_
Consider the above.
If you have friends and family who relentlessly pour data into Discord, WhatsApp, Telegram, Facebook, "the phone" and SMS, or even 501c3-Signal (sees all metadata), take some time to think about what strata they are of and what their lives are ultimately worth, by their own definition as espoused by their actions, choices, and thought (or lack thereof).
With a bird's eye view of your social graph, if you aren't already doing cicd privately for Bootstrappable Builds of your own software stack or aren't paying some elite literate team to do that for you, nor are you itching to, that bird's eye view of your social graph might also help you understand what class you are of.
_
I know what strata I am of.
Here is the reality. Some people are actually better than some other people, morally and metaphysically. If anyone derides you for acknowledging this truth, they're telling you what strata they are of (and belong in).
As a general rule of thumb, the first AS immediately outside the edge device be that a laptop with a 5G WWAN card or the router of the LAN must not be able to see anything other than QUIC or TLSv1.3, either of with encrypted hello, or IPsec or Wireguard packets.
And if the remote end is available over the local region's mesh network so to not use any commercially operated AS, even better.
Somewhere in early 2013 some ethical hacker communities had tooling to share the hashes and general metadata of downloaded videos from Youtube so that "spy marks" could be detected.
At the time I was already concerned that what would later be called deep fakes would be abused by big sites to mass-manipulate the bifurcated segments of the larger population in near real-time. At that time in 2013 I was told I must be smoking some really good shit, and perhaps I was.
But now in 2026 about twelve years after Google's primitive artificial neural networks showed us an on-silicon view of tripping balls in a grocery store, and now the mediocre enthusiasts both technical and not are no longer like "oh yeah that's cool man" but has been exposed to what artificial neural networks are doing day to day, the concern for targeted convincing-as-totally highly manipulative edits of hour long podcasts is not so "out there".
Because Postgres hasn't adopted that yet, and I'm not aware of any actual plan to adopt it? Tom Lane just did an interview where he said he doesn't see any world where they move away from dead tuples and vacuuming.
The MVCC article is good but feels like it's trying too hard to be a "on one hand, on the other hand" kind of analysis. Postgres is the only database that uses its design because, as the article admits at the end, it has "operationally loud failure modes".
Compare Postgres and Oracle (block undo based) for what happens when the database is underprovisioned:
• Postgres: bottlenecks on CPU. The database falls behind on vacuuming and dies.
• Oracle: bottlenecks on free disk space. Individual long running statements, SNAPSHOT and READ ONLY transactions get cancelled with a "snapshot too old" error.
In Oracle the database continues running and the blast radius is limited to a single statement. Because it's the longest running statements that die first, that almost certainly means an asynchronous business report and not live user traffic - which is exactly what you'd hope for. Most businesses can tolerate a missing day in a report much better than customer-facing outages, and fixing it is just a single SQL statement if you have free disk space (adding more storage is easy due to the SAN).
That's much preferable! How many post mortems do we see on HN from some startup bemoaning a multi-hour outage caused by Postgres' MVCC choices? Quite a lot. Now think about how often do you recall reading a post mortem of an outage at some big bank, hospital, shipping port etc that traces back to Oracle's MVCC engine? I don't think I ever read one. The startup world likes to make fun of Big Enterprise, but they have a much better track record of database uptime because they stay away from vacuum-based MVCC.
Disclosure: I have a part time role in the Oracle DB group. Unapproved opinions may be found above, caveat emptor.
The Postgres approach to MVCC ("append-only storage" in the jargon of https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postg...) is mandatory if you actually return object addresses to the client and thus need pointer stability (I've implemented such a DB). However, Postgres doesn't actually have this requirement so it makes little sense in that context. The beauty of undo log-based MVCC is that all versions superseded by a committed transaction are freed at the same time and from the same contiguous region of memory or disk, which makes it both memory- and SSD-friendly ("grouping by death time" in the jargon of https://research.cs.wisc.edu/wind/Publications/nvmw18-he.pdf).
Yes. This is the thing that tripped me the most when learning postgres internals. It was obvious that append-only enabled stable addressing but then it just never materializes. I was incredibly perplexed. Surely I'm missing something right? Nope!
Postgres folks will need to correct me but I believe the append-only MVCC design originated from the original "time-travel" requirement (which IIRC was soon dropped). There are better approaches to time-travel anyway such as time-split B-trees (https://www.microsoft.com/en-us/research/wp-content/uploads/...).
You can do time travel with any MVCC design. Undo logging is well suited to it and Oracle ships several forms of time travelling SQL under the name Flashback.
The simplest form of Flashback just uses the undo logs. Normally undo is deleted once no live transaction uses it, but you can set a retention time to allow SELECT ... AS OF ... queries to go back at least that far.
However, keeping undo logs around forever isn't practical. If you want to go back a year then there's Flashback Time Travel which copies old data into tables in a form that the query engine can use to answer AS OF queries more efficiently.
Hah, interesting. I need to investigate that data structure. I don't know if Flashback uses it either - if you enable the time travel feature then undo logs are processed into internal tables partitioned by SCN, but I suppose it's possible those tables are stored in a different way to regular heap-organized or index-organized tables.
The nodes in a time-split B-tree tile the 2-D time/primary-key space in an arbitrary way except they must cover it fully with no overlaps (think of each node as an arbitrary rectangle with primary key as one axis and time as the other). That gives you a lot of freedom in how you partition the space, allowing you to exploit local sparsity in either the time distribution or the primary key distribution.
Yes and that would make sense, and what I would expect, if it were available. I understand it is load-bearing but it is nonetheless surprising that it hasn't been revisited. It is surprising, at least to me, that time-travel never shipped given its feasibility.
The boringsql article was very informative, if you can get past some flourishes typical of a coauthor we all know:
> That's the honest shape of the mitigation: HOT is opportunistic, arrives in steady state rather than on demand, and quietly costs you 30% of your table size in reserved space.
Users of software often do not blindly do, or not do, whatever the upstream open source project does.
OrioleDB is friendlier to SSDs and is de facto "the other" MVCC of Postgres. OrioleDB may be still be "beta" but that hasn't stopped operators/users.
MariaDB has some alternative MVCC, one of them is particularly outstanding.
SSD endurance at scale has on and off been a major concern for me, so I empathize with that. Others deserve to know of OrioleDB, and Postgres more broadly is probably better off for it too.
All of the problems Uber had, could have been solved back then, had they actually asked for help on the mailing list. Several of the issues they had have also been fixed/changed in Postgres itself as a reaction to that discussion.
What Uber posted there did prompt me to investigate the topic of Postgres old MVCC, OrioleDB, and MariaDB's alternative MVCC.
Ultimately, one change in a row results in the entire row being written again, from what I read. Is this not accurate?
MariaDB's MVCC doesn't write the entire row again, only the delta. One of the newer more advanced MVCC for MariaDB are even more efficient.
In my view, "runaway vacuum" has never not been a case of either poorly done IT operations or poorly thought out (or just not thought out) database usage patterns by the in-house application developers. While "throw hardware at the problem" isn't a great answer, I have never not seen NVDIMM for ZFS ZiL/SLOG not mitigate "runaway vacuum", as ugly as that is -- that was a long time ago though.
SSD endurance can get daunting in an advanced hosting environment. It's odd that I don't often see others have these metrics in their Prometheus+Grafana. The people who are telling me that OrioleDB alleviates their endurance concerns aren't at liberty to show me their Grafana.
I might be able to get some real SSD endurance metrics comparisons at meaningful scale over the next couple years but I don't know.
Beyond that, I think the only real way to find out is a snapshot of real-world application production Postgres databases and use logical replication to replay a year of database traffic to find out what the delta on SSD endurance impact is.
I don't claim to be a Postgres expert relative to the upper echelon that frequents this site, always happy to get more insight to Postgres, my attention has generally been on either North or South side of that part of a webscale stack.
It's also hard to even claim they migrated from “PostgreSQL” to “MySQL”; they surely run MySQL underneath in their new system, but it's a really weird hybrid where it's basically only the storage engine. Even secondary indexes, on of their main points of contention in the article, is managed as a separate system on top of the database.
A compromise of engineers' endpoints should not lead to a compromise of wallet keys.
> A limited number of engineers at the company have direct access to wallets
Ah, so security models I spec'd and implemented for operating/administrating sensitive resources in/of production or just anything non-prod in general over the last decade, which never ever allow human users direct access outside of "break glass" (immediately instant-termination offense and lawsuit from company against employee if used frivolously), are superior to Binance's security, apparently.
inb4 "but how do u do tings den": the model has only so much cleverness but not that much, I'll keep it proprietary for now thx
Ya'd think a place like Binance would use a managed Qubes OS offering for endpoints. And yes, Qubes can be made derpy-derp-friendly with a custom UI layer and backing of provider's cicd for any/all apps including Windows apps like MS Excel with full GPU support.
The original model for web content distribution wasn't designed with Cloudflare style reverse proxies and they weren't a thing until much later. The original model is for the most part dead, sans some quiet corners here and there.
The original model for web didn't include REST style API calls.
A new model designed holistically for content distribution, with a hardened standardized spec for the API calls part, something that by design entirely shirks today's daily challenges, is necessary.
_
> Or just come back read the comments on hn for that article.
reply