One Postgres. Two schemas.

01 Where the database lives.

The Postgres container is postgres-pgvector on Unraid, network br0.2, image timescale/timescaledb-ha:pg16. The choice of the TimescaleDB image isn't really about time series — it's that the HA image ships with pgvector and a fat catalog of useful extensions preinstalled. Nothing in BawtHub depends on hypertables today.

Both llm-bawt-app on echo (10.0.0.101) and bawthub-frontend (also on echo) reach Postgres over the LAN. Connection strings are configured via LLM_BAWT_POSTGRES_* environment variables for llm-bawt and a single DATABASE_URL for the Prisma client in the BawtHub frontend container.

02 Schema layout.

Despite living in the same database, the two services' tables don't overlap and there are no cross-schema joins. Each side treats the other's data as opaque — when BawtHub needs message history it calls llm-bawt's REST API; when llm-bawt needs avatar metadata it doesn't, because it isn't llm-bawt's concern.

03 Memory (per bot, plus shared sessions).

The five-layer memory model is covered in its own page; this is the disk-level view. Per bot, llm-bawt creates three tables — {bot}_messages, {bot}_memories, {bot}_forgotten_messages — by sanitizing the slug into a table name and running CREATE TABLE IF NOT EXISTS on first access. The memories table has a 384-dim pgvector embedding column added via raw SQL because SQLAlchemy doesn't ship a native pgvector type.

The per-bot pattern means table count grows linearly with bot count. That's deliberate — it keeps each bot's vector index small and makes "drop this bot" an actual DROP TABLE, not a tombstone migration. The downside is cross-bot search has to fan out, which the memory_search_all MCP tool handles.

04 Identity tables (shared).

Unlike memory, identity is shared across bots. A fact about Nick shouldn't have to be relearned by Snark, Mira, and Codex independently.

The agent_backend_config.session_key field is where bridges write the SDK-internal thread/session UUID — for Claude Code it's the Agent SDK session, for Codex it's the thread_id. When you send /new as your first word, the chat-routes handler clears this field, and the next turn starts a fresh upstream conversation.

05 Runtime + turn logs.

Every chat completion gets a row in turn_logs, persisted at request-start with status="streaming" so even a backend crash leaves a trace. The row gets backfilled with prepared messages, tool call details, response text, latency, and final status as the turn progresses.

Turn logs have a TTL — default 168 hours — and a periodic cleanup job. Tool call records persist alongside their parent turn. The trigger_message_id column on turn_logs is what lets the frontend tie a turn log back to the user message that started it; the column was backfilled retroactively when the field was added.

06 The OpenClaw event archive.

Streaming events live in Redis (see the streaming page) — but every event is also persisted to Postgres for replay and durability:

07 The prompt registry.

System prompts and reusable prompt templates are versioned. prompt_templates holds the named template (e.g. "memory_consolidation", "fact_extraction"); prompt_template_versions stores every edit with the body and a timestamp. The /tools/prompts page in BawtHub is the editing UI.

This isn't speculative — most of the memory pipeline (consolidation, fact extraction, profile resolution) is driven by templated prompts the operator can iterate on without redeploying code. The active version is the latest version unless one is explicitly pinned.

08 BawtHub: presentation tables (Prisma).

The BawtHub frontend owns its own schema at frontend/prisma/schema.prisma. These tables back the UI's non-chat surfaces — dashboards, avatar config, the agent task system.

09 Two ORMs, no foreign keys across the boundary.

The boundary is intentional. Prisma manages its own migrations via prisma migrate; llm-bawt manages its own DDL via SQLAlchemy create_all plus targeted ALTER TABLE IF NOT EXISTS statements for schema additions. Neither side knows about the other's tables — when the frontend wants chat history it goes through llm-bawt's REST surface at /v1/history, not a direct join.

This buys two things: clean ownership of migrations (no need to coordinate Prisma migrations with Python ones), and the freedom to host the two services against different databases later if it ever makes sense. Today they share one Postgres instance because that's the simplest thing that works.

10 Redis is the other data store.

Not everything is in Postgres. The Redis container (llm-bawt-redis, redis:7-alpine) is configured with --maxmemory 128mb --maxmemory-policy allkeys-lru — a transient bus, not a database. It holds:

• Streams for events, commands, and run responses — capped at maxlen ~10,000 per session (per-session events), 5,000 per request (run streams), or 5,000 for unified bot+user event streams.
• Short-lived RPC reply streams with 60-second TTLs for cross-process function calls.
• History-persist commands (agent:history, maxlen 1,000) that the main app consumes to keep bot chat histories in sync with the gateway.

Nothing in Redis is durable past restart. Postgres is the source of truth; Redis is just the fast path between processes.

11 Backups.

The Postgres cluster is dumped nightly to NAS storage as part of the broader Unraid backup routine. Memory tables are large (snark_messages alone is ~2,500 rows of conversation history at the time of writing); the dump runs against the live database with pg_dump --clean --if-exists. There's no streaming replication today — single-node Postgres on Unraid, point-in-time recovery via dpkg-backed restore, daily granularity.

The infra-backups agent skill covers the monitoring side; verification of dump freshness is a separate routine on the host.

12 Key files.