isolation
shared DB
One shared Postgres with a tenant_id column — a bug or leak crosses agents.
a2a per-agent
A dedicated managed Postgres per agent. Isolation is the boundary, not a WHERE clause.
a database per agent
Managed Postgres for AI agents, one per deploy.
Shared databases isolate tenants with a WHERE clause — the kind of boundary a bug walks right through. On a2a cloud, every `a2a deploy` provisions a dedicated, managed Postgres for that agent: a real isolation boundary, a clean audit boundary, and pgvector memory built in. You get a connection string, not a database to babysit.
isolated · pgvector memory · scoped access
0
databases per agent
0
shared tenant columns
pgvector included
the problem
A tenant column is not an isolation boundary.
The default way to give agents a database is a shared Postgres partitioned by a tenant_id column. It works until a query forgets the filter, an injection slips the WHERE clause, or an incident review asks which agent touched a row and the answer is 'all of them share the table.' Meanwhile agent memory needs vectors, so you bolt on a second store to provision and keep in sync. Isolation, audit, and memory each become a project.
Tenant isolation enforced in application code — one missing filter crosses agents.
A separate vector store to provision and keep consistent with relational state.
Data-access questions span a shared schema instead of resolving to one agent's store.
A standing superuser connection string baked into the agent image — ambient data access.
the a2a way
Every agent gets its own isolated, managed Postgres.
The database is a first-class part of a deploy, not something you wire up after. Per-agent isolation gives you a boundary for blast radius and audit; pgvector gives you memory in the same store; scoped grants replace ambient access.
One database per agentpgvector memory built inAn audit boundary, not just storagePer-agent credential, honestly describedManaged lifecycleIsolation you can migrate
One database per agent
Every `a2a deploy` provisions a dedicated, managed Postgres for that agent. Not a shared cluster with a tenant column — a real isolation boundary, so one agent's data and blast radius stay its own.
pgvector memory built in
The database ships with pgvector, so agent memory, embeddings, and retrieval live next to relational state. No separate vector store to run, sync, or reconcile — one connection string for facts and recall.
An audit boundary, not just storage
Because the database is per-agent, its storage boundary maps to one deployed agent instead of a shared tenant column. Execution receipts identify the agent and run, but they do not record database queries or row access by default.
Per-agent credential, honestly described
The platform projects a per-agent database connection credential into the hosted container. Database access is isolated by the dedicated database and credential; it is not universally mediated by audience- and TTL-bound grants.
Managed lifecycle
Provisioning, upgrades, and backups are handled by the platform. You get a connection string on deploy; you don't get a Postgres to babysit, patch, or capacity-plan per agent.
Isolation you can migrate
Per-agent boundaries make an agent portable: its state is its own database, not entangled in a shared schema. Tear one agent down, or lift it, without a cross-tenant data untangling exercise.
side-by-side
Shared multi-tenant DB vs. per-agent Postgres.
vector memory
shared DB
A separate vector DB to provision, sync, and keep consistent with relational state.
a2a per-agent
pgvector in the same database — embeddings and facts behind one connection string.
audit
shared DB
'Which agent touched this?' means auditing a shared multi-tenant schema.
a2a per-agent
Data belongs to one agent's store; receipts identify those runs but not individual SQL activity.
access
shared DB
A standing superuser connection string baked into the agent image.
a2a per-agent
A per-agent connection credential projected at runtime, separate from the image and from grant-backed workspace access.
operations
shared DB
You provision, patch, back up, and capacity-plan a database per service.
a2a per-agent
Managed lifecycle — a connection string on deploy, no Postgres to babysit.
dimension
shared DB
a2a per-agent
isolation
One shared Postgres with a tenant_id column — a bug or leak crosses agents.
A dedicated managed Postgres per agent. Isolation is the boundary, not a WHERE clause.
vector memory
A separate vector DB to provision, sync, and keep consistent with relational state.
pgvector in the same database — embeddings and facts behind one connection string.
audit
'Which agent touched this?' means auditing a shared multi-tenant schema.
Data belongs to one agent's store; receipts identify those runs but not individual SQL activity.
access
A standing superuser connection string baked into the agent image.
A per-agent connection credential projected at runtime, separate from the image and from grant-backed workspace access.
operations
You provision, patch, back up, and capacity-plan a database per service.
Managed lifecycle — a connection string on deploy, no Postgres to babysit.
questions
Frequently asked.
Does every AI agent get its own Postgres database?
Yes. Every `a2a deploy` provisions a dedicated, managed Postgres for that agent — not a shared cluster with a tenant column. Each agent's data lives behind its own isolation boundary, which contains blast radius and makes the database a clean audit boundary for that agent's runs.
Why a per-agent database instead of a shared multi-tenant one?
A shared database often enforces tenant isolation in application logic. A per-agent database and credential give each deployment a separate normal access boundary and make migration simpler. Receipts identify those runs, but current sealers do not claim SQL statements or row access as signed fields.
Does the managed Postgres support pgvector for agent memory?
Yes. The per-agent database ships with pgvector, so embeddings, semantic memory, and retrieval sit alongside relational state behind one connection string. You don't run or reconcile a separate vector store — agent memory and structured data share the same managed database.
How does the agent connect to its database?
The platform provisions and projects a per-agent connection credential into the hosted container rather than baking it into the image. That credential is ambient to the agent process while it runs, so it must be governed and rotated separately; scoped workspace grants do not mediate every database query.
Do I have to manage backups, upgrades, or provisioning?
No. The database lifecycle — provisioning, upgrades, and backups — is managed by the platform. You receive a connection string on deploy and never capacity-plan or patch a Postgres per agent. That's the point of managed Postgres for AI agents: per-agent isolation without per-agent operations.
keep reading
Related guides.
All guides live in the guides index.
no ambient trust
One deploy. One database. Its own boundary.
a2a cloud deploys any agent with dedicated managed Postgres, MCP and API surfaces, a frontend, and scoped grants. Agent API, public `/invoke`, and standard MCP `tools/call` executions receive Ed25519-signed receipts; formal A2A task routes remain protocol state.