Answers / vs Postgres

AvianSuite vs Postgres with an audit log

An audit table tells you what changed. AvianSuite is built for agents as writers: attribution, safe retries, conflict protection and undo by agent come with the first write, with nothing to build.

What an audit log leaves you to build

Audit triggers or temporal tables record old and new rows, but the current table is still the source of truth, and the agent's credential can usually update or delete rows in place. Everything else is code you write and maintain:

Attribution. The database sees one app user, not which agent or which run made the change, unless you pass that through on every write.
Retries. An agent that times out and tries again can insert the same thing twice unless you add idempotency keys.
Conflicts. Two agents updating the same record means the last write wins, silently.
Undo. Reversing everything one agent did in the last hour means writing and testing a script against the audit table, under pressure.
Tampering. Anyone with enough access can edit the audit table too.
Schema changes. Your business changes, and every new field means a migration on the table, its audit table and its snapshots, kept in step. Before long you're building and maintaining an app on top of the database just to keep the history straight.

What AvianSuite does

Flexible factsFacts are JSON. When the business needs a new field or a new kind of record, agents start writing it. There's no migration, and the history of every older record stays intact.

History is the dataEvery write is an event appended to a chain. The current state is replayed from it. The hosted API only appends.

Every write is attributedThe store sets the actor from the credential, so each change names the agent that made it.

Retries land onceEach write carries an operation ID. Sending it again returns the first result.

No silent overwritesA write against a stale state gets a conflict, and the agent reads again and decides again.

Undo by agent and timeundo_changes previews, then reverses, everything one agent did in a window. The undo is itself a change you can undo.

Tamper-evidentEach event's SHA-256 fingerprint covers the one before it, so a rewritten history shows up.

What it's built on

Stellar Jay is a single Go program per store with no database dependency: no Postgres, graph database or vector index behind it. Each store's history is AES-GCM-encrypted event files on disk, linked in a SHA-256 hash chain. Self-hosting means running that one program, or stellarjay-mcp pointed at it.

Using both

Keep Postgres for your application and give your agents AvianSuite. Agents read and write through MCP with full history, and when you need SQL reporting, export the current state as JSON into the database you already use.

How writes stay safe More answers