This is exactly right, and the article is clickbait junk.

Given the domain name, I was expecting something about the physics of information storage, and some interesting law of nature. Instead, the article is a bad introduction to data structures.

This line of thought works for storage in isolation, but does not hold up if write speed is a concern.

It's not pedantic, you are correctly using words as we understand them, and they are not. The headline needs a sharp correction. Editing jobs are in very short supply these days.

I mean if we're talking about the physical storage of medium, the single most dense way would be to write it on the surface of a black hole. I still haven't figured out how to read it back though.

In a similar vein, someone decided that everyone should have subdirectories under home named "Pictures", "Videos", "Music", "Documents", …

It _does_ open up amazing opportunities for compression though.

That's fine so long as there's an index!

That depends on the aim. The purpose of something determines how fitting the means are.

Also, let us not confuse "relative" with "not objective". My father is objectively my father, but he is objectively not your father.

One format I'm missing: storage for conversations and social media posts. Both are complex media (text + images/videos + metadata), and one is actually a collection of such posts.

How would you go about storing those in a somewhat human-readable format? My goal is to archive my chats and social media activity.

I would say Sqlite is closer, you find it on every phone, browser, server. I bet Sqlite files will be still readable in 2100. And I love Postgres.

Or (real) SQLite for reasonably scaled work.

I also like (old) .ini / TOML for small (bootstrap) config files / data exchange blobs a human might touch.

+

Re: PostgreSQL 'unfit' conversations.

I'd like some clearer examples of the desired transactions which don't fit well. After thinking about them in the background a bit I've started to suspect it might be an algorithmic / approach issue obscured by storage patterns that happen to be enabled by some other platforms which work 'at scale' supported by hardware (to a given point).

As an example of a pattern that might not perform well under PostgreSQL, something like lock-heavy multiple updates for flushing a transaction atomically. E.G. Bank Transaction Clearance like tasks. If every single double-entry booking requires it's own atomic transaction that clearly won't scale well in an ACID system. Rather the smaller grains of sand should be combined into a sandstone block / window of transactions which are processed at the same time and applied during the same overall update. The most obvious approach to this would be to switch from a no-intermediate values 'apply deduction and increment atomically' action to a versioned view of the global data state PLUS a 'pending transactions to apply' log / table (either/both can be sharded). At a given moment the transactions can be reconciled, for performance a cache for 'dirty' accounts can store the non-contested value of available balance.

Which implementation of Markdown is a correct Markdown? Why not org-mode syntax?

Claude Code vehemently agrees.

Or it's neither, and the intended effect is zero variation in the retrieval time, as when trying to avoid leaking secrets via timing attacks.

(Or I guess, more generally, the intended effect is zero correlation between the information and the time it takes to retrieve it. If retrieval time were completely random, it would achieve the goal, but it wouldn't have zero variation.)