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. The benefit is better use of available slots when demand differs between product categories; we have not verified a universal twofold capacity improvement. 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. Shared capacity can reduce unused reserved space, subject to handling, safety and occupancy constraints. 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.
The warehouse is an analogy, not a description of the database engine. Three terms deserve precise definitions:
- Polyglot persistence means using different storage technologies for different needs. It does not mean putting unrelated records in one container.
- Content-addressable storage identifies content by its hash. A database row ID that stays the same when the row changes is a different kind of identity.
- Log-structured merge-trees organize writes and sorted storage through flushing and compaction. They are not a synonym for dynamic business schemas or random warehouse slots.
Our mechanism is metadata-driven logical tables: definitions, columns and record payloads in shared PostgreSQL tables. A new business field can be stored as configuration that the existing application interprets.
An identifier helps locate a record. It does not make two copies self-correcting. Validation, reconciliation and recovery need explicit rules.
GOD CRM is built on the data version of this. Business records have identifiers and table definitions; supported structure can change through configuration. Accounts, chat and other service infrastructure also use dedicated tables. The core is open, MIT — clone it and read it.
godcrm.ai/git/holetron-lab/godcrm
Correction · 29 September 2026: Corrected polyglot persistence, content-addressable storage and LSM-tree definitions. Removed unsupported capacity and automatic-repair claims; the warehouse remains an analogy.