AI Signal 257 2 feeds carried it
Ampbase replaces its database with Tigris object storage, implementing constraints, transactions, indices, and history tables on top of it
↗
Ampbase founder JP explains how Ampbase uses Tigris global object storage as its sole persistence layer, manually implementing the four database behaviors, unique constraints, transactions, indices, and history tables, that a traditional database engine would normally provide.
For teams considering whether they can skip a relational database entirely, this is a concrete accounting of what that costs: you reimplement core database primitives yourself on top of conditional writes and strong read-after-write consistency. The post is candid about the risk, acknowledging the pattern of teams claiming they don't need a database and later migrating to Postgres.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Ampbase stores everything in two layers of Tigris buckets, a global directory bucket and one bucket per customer organization, using Protobuf for serialization to avoid managing a database schema layer.
Per-customer bucket isolation is enforced at the infrastructure level via Tigris' Partner Integration Program, eliminating the risk of missing org_id filters in application code.
The four database features Ampbase had to build manually are unique constraints, transactions, indices, and history tables, all implemented on top of object storage primitives like conditional writes and strong read-after-write consistency.
THE READ
What the cluster adds up to.
The core claim is that object storage can replace a database if you are willing to implement four primitives yourself: unique constraints, transactions, indices, and history tables. Ampbase does this on Tigris, which provides strong read-after-write consistency and conditional writes as the building blocks. The post walks through how each primitive maps to specific key patterns in two bucket layers, a global directory bucket and a per-customer org bucket.
Storage is organized as JSON or Protobuf objects keyed by paths that encode the database behavior each key implements. For example, channel-slugs/{slug}.json serves as a unique constraint, config-versions/{version_ulid}.json acts as a history table, and active-config.pb is an in-place-overwritten pointer. The team migrated from JSON to Protocol Buffers to reduce marshaling overhead, noting that the tradeoff is immutable Protobuf field names, comparable, they argue, to the pain of renaming columns in Postgres or MySQL.
Per-customer isolation is handled not by application-level filtering but by infrastructure-level bucket scoping. Each customer becomes a Tigris organization with its own bucket and scoped access keys, so credentials that reach one customer's data cannot address another's. The author highlights this as the area where most platform builders make mistakes, since traditional multi-tenant databases rely on WHERE org_id = ? clauses that can be forgotten.
The author is unusually candid about the risk of this approach, explicitly referencing the recurring pattern of teams declaring they don't need a database and later publishing a post about migrating to Postgres. The post is framed as a transparent breakdown of what building these primitives costs, so readers can evaluate whether their own use case warrants the same tradeoff. Only one feed carried this story, so there is no independent corroboration of the approach's long-term viability.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER