2026-06-26 · Architecture
The liquid database
Amazon's fulfillment centers don't sort by product. A phone case can sit between a paperback and a frying pan. Each item goes into whatever slot is free, and a barcode records the address. After it stopped giving products fixed homes, Amazon reportedly fit about twice as much stock into the same buildings. The logistics name for it is chaotic storage — random slotting, dynamic storage. The German term, Chaotische Lagerhaltung, states the rule plainly: a part has no fixed location; it goes wherever there's room, and the address is recorded automatically. Automated high-bay warehouses run the same way.
Fixed shelves waste space. Reserve a zone per category and demand never matches the partition — one bin overflows while another sits half-empty. Static partitioning always pays for rigidity in empty space; the formal name for that waste is internal fragmentation. Drop the partitions and fill rate climbs toward 100%. The cost moves from wasted space to a single requirement: every item must carry its own address.
A liquid database is that principle moved into data. The structure doesn't sit above the data as a fixed schema — it lives inside the data itself.
This isn't a new dream. It rests on ideas that already shipped and have names:
- Polyglot persistence — Martin Fowler's term for unrelated things sharing one container, no single schema required.
- Content-addressable storage — a record is reached by what it is, not by a line in a separate registry. Its hardware ancestor, content-addressable memory, dates to the 1950s. You already use a CAS daily: Git names every object by the hash of its contents, and IPFS addresses the whole web that way.
- Log-structured merge-trees — the engine writes into any free extent and records the location instead of reserving space by type. The same move as the warehouse, and it's what RocksDB and Apache Cassandra run on in production.
The address living in two places — on the item and in the index — isn't redundancy. It's what makes the system self-correcting. The index answers "where is X?" in one step. The label on the item answers "where does this belong?" when the index is wrong. An audit reconciles the two: agree, and nothing happened; disagree, and the physical label wins and the index is fixed. Two independent witnesses to one fact, each repairing the other. Durability usually costs speed; here the index buys read speed and the label buys recoverability at once.
GOD CRM is built on the data version of this. Everything is a row, the rows carry their own type and address, and the schema follows the data instead of caging it. The core is open, MIT — clone it and read it.