Object storage is all you need
22 days ago
- Ampbase uses Tigris object storage (built on FoundationDB) as its primary storage layer instead of a traditional relational database.
- They implement needed database behaviors on top of object storage primitives: strong read-after-write consistency and conditional writes (If-None-Match/If-Match).
- Uniqueness is enforced via conditional writes with If-None-Match:*; conflicts require re-reading the stored object to determine the outcome.
- Mutations without transactions use optimistic concurrency: read ETag, compute new state, write if ETag matches, and retry with backoff. Mutation functions must be pure to avoid side effects per attempt.
- Indices are designed into key names, e.g. members/{sha256(email)}.json, enabling O(1) point lookups—but only for questions anticipated in advance.
- History and audit trails use append-only ULID keys, leveraging lexicographic ordering for time-ordered range scans. Since there is no UPDATE path, records cannot be lost.
- Pain points include read amplification from repeated reads and fan-outs, the necessity of a read-through cache, no joins/ad-hoc queries, and no atomicity between state updates and event log appends.
- Cross-region eventual consistency can break conditional writes: the same compare-and-swap operation in two regions may both succeed, but one update is lost. Their workaround is replaying dependent RPCs to a single primary region and making other writes loud errors.
- Analytics evolved from ClickHouse sampling to host-side reduction: small, aggregated, append-only files read with DuckDB, which also improved tenant isolation.
- The design works because writes are low-volume and uncontended, reads are point lookups, data partitions cleanly per organization, and history is append-only. It would be abandoned if multi-key transactions or ad-hoc queries became necessary.