There are a lot of complexities, and solutions aren't as simple as one would imagine. I'm going to assume MySQL, but other relational dbs work similarly. > Tr

There are a lot of complexities, and solutions aren't as simple as one would imagine. I'm going to assume MySQL, but other relational dbs work similarly. > Transactions shouldn't slow this down (it's possible to write all the data to new areas of diak, and then the final 'commit' is a metadata update to say those new areas are active). This is done already. DBs don't write directly to the buffer pages, they write to a sequential log (the WAL), because sequential writes are faster. A separate thread reads the WAL and applies the changes. This is actually not even the whole story. Pages are written twice, to the so-called doublewrite buffer, because "filesystems are complicated", and writing a page is not in itself a guarantee of atomicity (this is a way more complex discussion than it seems). > But it's possible to design an index where updates are coalesced, and therefore the changed parts of the index are only written once as a single bulk write This is done already as well, by the so-called "change buffer" (https://dev.mysql.com/doc/refman/8.0/en/innodb-change-buffer.html https://dev.mysql.com/doc/refman/8.0/en/innodb-change-buffer...). --- The most important concept is: sequential writes (as in: big batch of writes) are not possible in ACID dbs, because changes must be written immediately. Due to the durability guarantee, one can't buffer them in memory, and pretend that they have been written. Battery-backed controllers can be used to improve write throughput, but that's another story.