JP from Ampbase walks through how they replaced their database layer entirely with Tigris object storage plus hand-rolled primitives built on conditional writes and strong read-after-write consistency. The system uses two-tier bucket organization (global directory + per-org buckets) and implements uniqueness constraints, mutations, indices, and audit trails using hash-based keys, compare-and-swap operations, and append-only ULID-sorted objects. The honest part: read amplification is severe—every request hits the directory bucket N times across N instances, plus fan-outs from list operations create dozens of round trips where a single SQL query would suffice. They cache aggressively. Multi-region conditional writes silently lose updates when both regions approve the same compare-and-swap before replication converges. They work around this by routing mutation RPCs to a single primary region. The design only works because Ampbase's specific constraints: low-volume uncontended writes, point-lookup reads on known keys, clean per-org partitioning, and naturally append-only history. The analytics hook is revealing: they didn't find a clever object-storage analytics solution. They changed what data they collected instead—moving aggregation to the host so only pre-rolled sketches reach storage, then querying those files with DuckDB rather than a warehouse. One sharp question: the source doesn't explain how the primary-region enforcement (replaying cross-region mutations back to primary) survives leader failure or partition without introducing a separate consensus layer—is that handled in code they didn't discuss here?