← Thu, Sep 10 digest

Object storage is all you need

read article ↗ hn thread ↗

summary

Ampbase replaces traditional relational databases with Tigris object storage by implementing essential database primitives—unique constraints, transactions, and indices—directly on top of strong read-after-write consistency and conditional writes. This approach eliminates the overhead of schema migrations and connection management, provided the application's data patterns involve low-volume writes and predictable point lookups. While it simplifies the infrastructure, it shifts the complexity to the application layer, requiring manual handling of read amplification and eventual consistency across regions.

key points

  1. Database behaviors like uniqueness and mutation are achieved using HTTP preconditions such as If-None-Match and If-Match, which allow for compare-and-swap operations to prevent data loss and duplication.
  2. Indices and history tables are replaced by strategic key naming and append-only ULID-based storage, enabling O(1) lookups for known questions and automatic time-sorted audit trails without traditional indexing.
  3. The architecture suffers from read amplification and a lack of ad-hoc querying, necessitating a read-through cache and manual backfill jobs whenever new data access patterns are required.

who should read it

Software architects and backend engineers who are evaluating whether to use a traditional database or a simplified storage layer for their application's state management.

discussion skeptical

consensus

Commenters largely view the approach of building a custom database layer on object storage as an unnecessary reinvention of the wheel. They argue that existing tools like Postgres, FoundationDB, or Iceberg already solve these problems more reliably and efficiently. The general sentiment is that developers should focus on solving their core business problems rather than spending 'innovation tokens' on basic infrastructure.

top insight

The discussion highlights a critical distinction between building a tool for fun (like game engines) and building for production; while custom implementations can be intellectually stimulating, they often lead to unfinished projects and operational fragility. This is contrasted with the reality that most modern infrastructure needs are already met by a wide array of specialized object-storage-native systems.

Generated by an LLM from the article and thread. Check the sources before relying on it.