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

Database memory uses a relational database (SQLite, Postgres, MySQL) with standard CRUD operations to store agent state. It provides strong consistency, column-level type enforcement, and fast structured queries.

The standard approach is to update rows in place. This gives you the current state but loses previous values unless you build audit tables, trigger-based history tracking, or an event log on top. Without that additional architecture, a database is a mutable snapshot store.

\-- Agent A writes a value
UPDATE contacts SET city = 'Barcelona' WHERE name = 'Ana Rivera';

-- Agent B overwrites it
UPDATE contacts SET city = 'San Francisco' WHERE name = 'Ana Rivera';

-- Previous value is gone. No conflict detection, no history.
SELECT city FROM contacts WHERE name = 'Ana Rivera';
-- -> 'San Francisco'

Databases are familiar and powerful, but standard CRUD usage actively works against memory guarantees. You can build versioning, audit trails, and conflict detection on top of a database, but at that point you are building the observation/reducer architecture that Neotoma already provides. See [deterministic memory](/deterministic-memory), [silent mutation risk](/silent-mutation-risk), and [Neotoma vs database memory](/neotoma-vs-database).