/dev/null is an ACID compliant database
Humorous framing of /dev/null as a database
- Most comments lean into the joke:
/dev/nullas the perfect, infinitely scalable, ACID- and CAP-compliant “database” with zero bugs, no support issues, and massive cost savings once all data is piped into it. - People riff on real-sounding productization: “Null as a Service” (NaaS), devnull-as-a-service.com, enterprise policies with
/dev/null0and/dev/null1, audits, and DR runbooks. - Support and analytics jokes: routing tickets and logs to
/dev/null“solves” reliability and throughput problems.
ACID, CAP, and pedantic pushback
- Several point out that
/dev/nullis not actually a database, more a storage sink. - Durability is debated: some argue it trivially satisfies durability because nothing is stored; others insist durability refers to preserving user data, which clearly fails here.
- Similar nitpicks about “state transitions” when there is effectively only one state, and that the joke relies on colloquial, not formal, definitions of ACID.
Real-world behavior and failure modes
/dev/nullcan fail in practice: missing/dev, running out of file descriptors or memory, or/dev/nullbeing replaced by a regular file or a different device (allowing data capture or system instability).- Disaster recovery is tongue-in-cheek: you can recreate it with
mknodandchmod, and “all the same data will be there” because it’s always empty.
Performance, scalability, and “web scale”
- Benchmarks show tens of GB/s when writing
/dev/zeroto/dev/null; others test pipes (yes | pv) and observe pipe or tool overheads. - Many jokes about horizontal sharding, global sharding “across the universe,” Kubernetes deployments, and “Heisen-throughput” that scales as high as you can measure.
Related satire and analogies
- References to S4 (Super Simple Storage Service), write-only memory, “mangodb,” nocode, supersimplestorageservice.com, and pipe-logic/circuit analogies.
- A few criticize the joke as weak or sloppy; others defend it as classic nerd humor and a “trivial solution” that usefully highlights how ACID/CAP definitions can be vacuous.
Security / tampering angle
- One concern: a privileged user can replace
/dev/nullwith a normal file or different device, allowing interception of “discarded” data.