What is SapixDB?

The Problem with Existing Databases

Modern databases were designed for a different era — one where humans wrote queries, schemas were defined upfront, and trust was handled by a policy document nobody read. That era is over.

Today, AI agents query, write, and reason about data continuously. They need to know not just what the data says, but who wrote it, when, and whether it can be trusted. They need schemas that grow alongside new discoveries, not ones that require a migration ticket and three weeks of planning.

SapixDB doesn't add features to fix these problems. It eliminates them by design.

How SapixDB Thinks About Data

SapixDB is built on a biological metaphor that maps one-to-one to real engineering primitives. Understanding these six concepts is all you need to get started.

Spin Up Your First Agent

SapixDB runs as a standalone process. Each agent is its own instance, exposing a REST API on a configurable port. Here's everything you need to get started.

1. Start the agent

Set your data directory and agent identity, then start the process:

SAPIX_AGENT_ID=my-agent \
SAPIX_STRAND_DIR=./data \
SAPIX_PORT=7475 \
sapix-agent

The agent creates its Ed25519 keypair on first boot and stores it alongside the strand. It will not generate a new keypair on restart — identity is stable.

2. Initialize the strand

Every agent starts with a genesis record — the root of its chain:

POST /v1/genesis
{
  "agent_id": "my-agent",
  "description": "Customer data agent for Acme Corp"
}

{
  "record_id": "019...",
  "hash": "3a7f...",
  "parent_hash": null,
  "sequence": 0
}

The genesis record is the only record with a null parent_hash. Every subsequent write will chain from here.

Appending Records to the Strand

You write data by appending a record. The payload is your data as a JSON object — SapixDB encodes it as MessagePack internally and signs the block before storing it.

POST /v1/records
{
  "payload": {
    "type": "customer",
    "name": "Lena Fischer",
    "email": "[email protected]",
    "plan": "enterprise"
  }
}

{
  "record_id": "019...",
  "hash": "7c2a...",
  "parent_hash": "3a7f...",
  "sequence": 1,
  "signed_by": "my-agent",
  "timestamp_hlc": 1748736000000
}

Every response includes the hash of the new record, the hash of its parent, and the agent that signed it. This receipt is all you need to verify the chain at any future point in time.

Superseding a record

Records are immutable — you never update them. Instead you write a new record that supersedes the old one. The previous record stays in the chain forever:

POST /v1/records
{
  "payload": {
    "type": "customer",
    "name": "Lena Fischer",
    "email": "[email protected]",
    "plan": "enterprise"
  },
  "supersedes": "7c2a..."
}

The original record is still there. Time travel is always available — see the Querying section below.

Tombstoning (logical delete)

POST /v1/records
{
  "payload": { "type": "customer", "id": "019..." },
  "flags": 2
}

flags: 2 writes a TOMBSTONE record. The data is not physically deleted — it is logically marked as removed. The chain is never truncated.

Asking Questions in Plain Language

SapixDB ships with SaQL — a semantic query layer that accepts natural language goals and translates them into precise strand operations. No SQL. No schema required.

SaQL queries

POST /v1/query
{ "query": "latest 10 records" }

POST /v1/query
{ "query": "records from the last 24 hours" }

POST /v1/query
{ "query": "record with hash 7c2a..." }

Time travel

Because every record is hash-linked with a Hybrid Logical Clock timestamp, you can query the exact state of any agent's data at any point in the past:

GET /v1/strand/as-of?ts=2026-05-01T15:30:00Z

{
  "as_of_ts": 1746113400000,
  "records": [
    {
      "hash": "7c2a...",
      "payload": { "name": "Lena Fischer", "plan": "enterprise" },
      "signed_by": "my-agent",
      "valid_from": 1746100000000,
      "valid_until": null
    }
  ]
}

The response reflects the state of the strand as it existed at that exact timestamp. No backups. No snapshots. The chain is the time machine.

Reading the chain head

GET /v1/strand/head

{
  "head_hash": "9e1b...",
  "sequence": 42,
  "agent_id": "my-agent",
  "timestamp_hlc": 1748736001337
}

Connecting Agents and Traversing Relationships

Registering a peer agent

Agents discover each other through the mesh. Once registered, writes to one agent fan out to all peers automatically:

POST /v1/mesh/peers
{
  "agent_id": "inventory-agent",
  "endpoint": "http://10.0.0.2:7475"
}

Creating a relationship

POST /v1/graph/edges
{
  "src": "my-agent",
  "dst": "inventory-agent",
  "edge_type": "manages",
  "weight": 1.0
}

Traversing the graph across agents

A single traversal call performs BFS across your entire cluster, crossing node boundaries automatically:

GET /v1/graph/traverse?depth=2&edge_type=manages

{
  "start_agent": "my-agent",
  "agents_visited": ["my-agent", "inventory-agent"],
  "edges": [
    {
      "src": "my-agent",
      "dst": "inventory-agent",
      "edge_type": "manages",
      "across_peer": true,
      "peer_endpoint": "http://10.0.0.2:7475"
    }
  ],
  "depth_reached": 1
}

HIPAA and SOX — Structural, Not Bolt-On

HIPAA — PHI field classification

Declare which fields contain Protected Health Information. SapixDB will enforce access controls and log every read automatically:

POST /v1/hipaa/phi-fields
{
  "field_name": "email",
  "classification": "PHI",
  "reason": "email is a direct patient identifier under HIPAA §164.514"
}

Every read of a PHI field is logged with the requesting agent identity and timestamp. A full audit report is always available at GET /v1/hipaa/audit-report.

SOX — Dual-admin sign-off

Designate an agent as a financial (SOX Tier 1) agent. Any proposed schema change targeting that agent will require two distinct administrators to approve before it applies:

POST /v1/sox/designate
{
  "agent_id": "revenue-agent",
  "designated_by": "[email protected]",
  "reason": "owns financial transaction records"
}

The dual-sign requirement is enforced structurally — a single admin approval returns 403 regardless of permissions. There is no way around it.

SapixDB is in Private Beta

SapixDB is available today to a limited set of early partners. We are working directly with teams building agent-heavy systems in healthcare, financial services, and enterprise AI to shape the database for the next generation of applications.

If you are building something where you need:

• Provable data lineage without external tooling
• AI agents that own and understand their own data
• Compliance that is structural, not procedural
• Schemas that can evolve without migrations
• A database that scales by cell division, not by sharding

— SapixDB is built for you.