Nothing below you can do many writes at once

Why is atomicity always declared over one designated write rather than achieved?

Multiversion and optimistic schemes answered the question "which interleavings of concurrent transactions are allowed?". This article answers a different question: how does a database make a transaction's changes take effect all together, or not at all?

The constraint behind it is harsh. No layer below the database offers simultaneity. A disk or SSD gives you a write of one sector or one page at a time. The log gives you durability one flush (one fsync call) at a time. An object store gives you one object per request. Nothing in the stack provides the operation "make these n writes take effect together". There is no such primitive, at any price.

So atomicity is not achieved. It is declared. You find exactly one event that the layer below makes atomic by its own rules. Examples: a single sector write, a single log record reaching stable storage, a compare-and-swap on one pointer, a "create this file only if it does not exist" request. Then you define that one event to decide whether the other n writes count. Undo logs, redo logs, savepoints, in-doubt handling, manifest swaps: all of it is bookkeeping that defends this one declaration.

This gives the idea that organizes the whole article:

The idea also predicts something: when a substrate has no single atomic primitive, an external component will appear whose only job is to supply one. Keep this in mind until we reach object stores, where it is literally true.

The governing question for this article: what is your one atomic event, what does it cost to make durable, and how long is the window in which its outcome is unknown?