Neotoma vs Database Memory | SQLite, Postgres vs Deterministic State (Markdown)

Q: Why not just use SQLite or Postgres for agent memory?

A relational database provides strong consistency, but standard CRUD usage overwrites previous state on every UPDATE. Without an observation log, reducers, and provenance tracking, you get last-write-wins with no audit trail or conflict detection.

Q: Doesn't Neotoma use a database internally?

Yes. Neotoma uses SQLite locally and Postgres when configured. The guarantees come from the architectural pattern on top - immutable observation log, deterministic reducers, schema validation, and field-level provenance - not from the storage engine itself.

<!--
  Full-page Markdown export (rendered HTML → GFM).
  Source: https://neotoma.io/ca/neotoma-vs-database
  Generated: 2026-04-01T11:48:39.404Z
-->
# Neotoma vs database memory

A relational database (SQLite, Postgres) provides strong consistency, column types, and fast queries. But standard CRUD usage overwrites previous state on every UPDATE, losing history, provenance, and the ability to reconstruct past entity state. Neotoma uses a database as its storage backend but adds the observation/reducer architecture that delivers memory guarantees.

Relational databases are the default tool for structured data. The question is not whether a database can store agent state - it can. The question is whether standard CRUD patterns deliver the guarantees that production agent memory requires.

## Why not just use SQLite or Postgres for agent memory?

Database (CRUD)

A database with standard CRUD operations stores the current state of each entity as a row. UPDATEs overwrite previous values. There is no built-in audit trail, no observation log, and no mechanism to reconstruct historical state or detect conflicting writes from multiple agents.

Neotoma

Neotoma uses SQLite (or Postgres) as its storage backend but imposes an append-only observation log, deterministic reducers, schema validation, and field-level provenance on top. The database stores the data; the architecture delivers the guarantees.

◆

## Guarantee comparison

| Property | Database (CRUD) | Neotoma |
| --- | --- | --- |
| Deterministic state evolution | Not provided | Guaranteed |
| Versioned history | Not provided | Guaranteed |
| Replayable timeline | Not provided | Guaranteed |
| Auditable change log | Not provided | Guaranteed |
| Schema constraints | Partial | Guaranteed |
| Silent mutation risk | Common risk | Prevented |
| Conflicting facts risk | Common risk | Prevented |
| Reproducible state reconstruction | Not provided | Guaranteed |
| Human inspectability (diffs/lineage) | Partial | Guaranteed |
| Zero-setup onboarding | Not provided | Not provided |
| Semantic similarity search | Not provided | Guaranteed |
| Direct human editability | Not provided | Not provided |

◆

## When to use which

Use Database (CRUD) when

You have a single writer, do not need historical state reconstruction, and are comfortable with last-write-wins semantics. Standard application development patterns are sufficient for your use case.

Use Neotoma when

Multiple agents write to the same entities. You need to know what was true at any past moment, resolve conflicts deterministically, enforce schemas across writers, or prove provenance for audits. You want the guarantees without building the architecture yourself.

## Common questions

### Doesn't Neotoma use a database internally?

Yes. Neotoma uses SQLite locally and Postgres when configured. The guarantees do not come from the storage engine - they come from the architectural pattern on top: immutable observation log, deterministic reducers, schema registry, and field-level provenance tracking.

### Can I add audit tables to get the same guarantees?

You can build audit triggers, history tables, and event logs on a database. If you also add deterministic merge logic, schema validation, provenance tracking, and idempotent observation handling, you will have rebuilt Neotoma's architecture. The question is whether that is the best use of your engineering time.

### What about temporal databases or event-sourced schemas?

Temporal extensions (e.g. Postgres temporal tables) and event-sourced patterns move in the right direction. Neotoma's contribution is the complete stack: content-addressed identity, deterministic reducers, schema-bound observations, and field-level provenance - integrated and tested as a single system.

[Install Neotoma](/install)[All memory models](/memory-models)[FAQ](/faq)