Storage

Database Choice

Myria v1 is intentionally PostgreSQL-native.

The service uses PostgreSQL for:

• append-only event storage
• snapshot registry
• topic metadata
• snapshot-scoped node membership
• node edges
• node refs

Core Tables

events

Stores the canonical event log.

Important columns:

• event_seq
• event_id
• source_event_key
• timestamp
• channel
• participants
• internal
• payload
• topic_hints
• created_at

Important key:

• partial unique index on (channel, source_event_key) when source_event_key is not null

topics

Stores exact derived topic metadata.

Important columns:

• topic_id
• context_id
• participants
• state
• label
• parent_topic_id
• created_at
• last_active_at

snapshots

Stores snapshot metadata:

• snapshot_id
• parent_id
• event_max_seq
• status
• builder version fields
• created_at

snapshot_registry

Stores the current active snapshot pointer.

nodes

Stores canonical node bodies:

• node_id
• node_type
• is_leaf
• participants
• summary
• metadata
• created_at

snapshot_nodes

Maps a snapshot to the nodes that belong to it.

node_children

Stores snapshot-scoped parent/child edges with explicit position ordering.

node_refs

Stores snapshot-scoped leaf-node refs back to raw events.

Only leaf nodes appear here.

Why Snapshot Membership Is Split Out

Node identity is content-addressed and excludes tree pointers, so Myria stores:

• canonical node bodies in nodes
• snapshot membership in snapshot_nodes
• snapshot-specific structure in node_children
• snapshot-specific refs in node_refs

This lets the service preserve stable node identity while rebuilding tree structure across snapshots.