ContextDB with Postgres, Supabase, or Hasura
Keep business truth in your database. Put action memory beside it.
ContextDB complements Postgres, Supabase, and Hasura. It does not replace them. Your system of record answers what exists. ContextDB evaluates what an agent may rely on before it acts.
Architecture
Two systems with different authority.
Your application reads authoritative business state from its current database. When an action depends on remembered context, the host asks ContextDB whether the evidence passes policy. The host then decides whether to perform the mutation.
Postgres / Supabase / Hasura authoritative business state ▲ │ read / write │ your agent host ▲ │ act / ask / abstain │ ContextDB memories · evidence · decisions · policy
Ownership map
Put each object where its meaning is clear.
| Object | Recommended home | Reason |
|---|---|---|
| Users and accounts | Your database | Authoritative identity and account state |
| Orders and inventory | Your database | Transactional business records |
| Agent memories | ContextDB | Source, confidence, provenance, and validity travel together |
| Action decisions | ContextDB | Outcome, reason, policy version, and evidence stay connected |
| Business-action receipt | Your host, linked to ContextDB | The host knows what actually happened in the downstream system |
Integration pattern
Check memory before the write.
# 1. Read authoritative state account = postgres.get_account(account_id) # 2. Evaluate remembered evidence for this action decision = contextdb.recall_for_action( user_id=account.user_id, query="change the renewal date" ) # 3. Enforce before mutation if decision.outcome == "act": postgres.change_renewal_date(account_id, decision.memories) elif decision.outcome == "ask": request_confirmation() else: stop_and_escalate()
Questions
How the boundaries work.
Do I need to move existing data into ContextDB?
No. Start with the action-relevant memories your agent needs across turns or sessions. Keep authoritative business records where they are.
Is user_id authentication?
No. In ContextDB it is a partition key. Your application remains responsible for end-user identity and authorization.
Who performs the final database write?
Your host does. ContextDB provides the action decision and evidence; your application must enforce that result.
Add one guard before one write.
Keep your current stack and test the action-memory boundary locally.