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
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.
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 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, a receipt's data access maps cleanly to one agent's store. 'Which agent touched this row?' has a boundary-level answer instead of a query across a shared multi-tenant schema.
Scoped access, no ambient trust
The agent reaches its database through scoped grants, not a standing superuser connection baked into the image. Access is bounded by audience and TTL — no ambient trust between a compromised run and your data.
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.
Shared multi-tenant DB vs. per-agent Postgres.
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 enforces tenant isolation with application logic — a WHERE clause a bug can skip. A per-agent database makes isolation a real boundary: one agent cannot read another's data even if its query logic is wrong or compromised. It also lets receipts' data-access records map cleanly to a single store, and lets you tear down or migrate one agent without untangling shared schema.
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 without ambient database access?
The agent reaches its database through scoped grants bounded by audience and TTL, not a standing superuser connection baked into the image. That means no ambient trust between a compromised run and your data — access is explicit and time-bounded, consistent with governed agent execution across the platform.
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.
Related guides.
All guides live in the guides index.
One deploy. One database. Its own boundary.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — with a dedicated managed Postgres (pgvector included), an MCP server, an API, a frontend, and an Ed25519-signed receipt for every run. Scoped grants instead of standing credentials, no ambient production access. The whole agent app, isolated, on one deploy.