Yugabyte released YugabyteDB 2026.1 alongside a new offering called AMP — Agentic Multitenant Postgres. The pitch is simple to state and harder to build: every tenant, or every AI agent in a multi-agent system, gets its own isolated, wire-compatible Postgres database, billed per CPU-minute, scaling to zero when idle. No shared schema, no row-level security policies standing between tenants, no per-instance minimum cost floor.
That's a genuinely different point in the design space from what most teams run today, and it's worth working through what problem it actually solves before deciding whether it matters for a given project.
The problem it targets
Most multi-tenant SaaS applications pick one of two models: a shared schema with a tenant_id column and row-level security (RLS), or one database (or schema) per tenant on a fixed-size instance. Both have well-known failure modes.
Shared-schema RLS is cheap to run — one Postgres instance, one connection pool, N tenants — but it concentrates risk. A missed WHERE tenant_id = ... clause, a bypassed RLS policy, or a slow query from one noisy tenant affects everyone sharing the instance. Connection pools get exhausted under bursty multi-tenant load because the pool is shared across every tenant's traffic, not sized per tenant.
Database-per-tenant on traditional managed Postgres (RDS, Cloud SQL) solves the isolation problem but multiplies the operational and cost problem. Fifty tenants means fifty instances, fifty sets of backups, fifty things to patch, and fifty monthly minimums even if half of them are nearly idle. This is exactly why most teams don't do it past a few dozen tenants.
AMP is an attempt to keep the isolation of database-per-tenant while removing the fixed-cost floor, by packing many small Postgres-compatible databases onto shared distributed infrastructure and billing only for CPU actually consumed. An idle tenant database costs nothing. A tenant that spikes gets more compute without a migration.
What database-per-tenant looks like today, concretely
A shared-schema setup typically looks like this:
-- One shared instance, tenant isolation via RLS
CREATE TABLE invoices (
id BIGSERIAL PRIMARY KEY,
tenant_id UUID NOT NULL,
amount NUMERIC NOT NULL,
created_at TIMESTAMPTZ DEFAULT now()
);
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.tenant_id')::uuid);
-- Application sets this per request/session
SET app.tenant_id = '3fa85f64-5717-4562-b3fc-2c963f66afa6';This works, but isolation is enforced by application discipline plus a policy that has to be correct on every table, forever. A database-per-tenant model removes that entire category of bug by making the boundary physical rather than logical:
# Provisioning a per-tenant (or per-agent) database on a serverless
# Postgres-compatible platform — conceptually how AMP-style provisioning works
psql "postgresql://admin@control-plane.example.com:5433" -c \
"CREATE DATABASE tenant_3fa85f64 WITH OWNER = tenant_role;"
# Each tenant/agent connects with its own database name, same wire protocol
psql "postgresql://app_user:***@cluster.example.com:5433/tenant_3fa85f64"No tenant_id column, no RLS policy to audit, no query that silently spans tenants because a WHERE clause got dropped in a refactor. The tradeoff moves from "get the isolation logic right in every query" to "manage N database objects," and AMP's bet is that automation and scale-to-zero billing make managing N database objects cheap enough to be worth it.
Where this actually fits
For AI agent architectures specifically, the case is stronger than for typical SaaS. An agent that spins up, does a burst of reads and writes against its own working memory or task state, and then goes idle for hours is a terrible fit for a fixed-size always-on instance — you're paying for idle compute most of the time. It's also a poor fit for shared-schema multitenancy, because agents are exactly the kind of workload that generates unpredictable, spiky query patterns that create noisy-neighbor problems for other tenants sharing the pool. Scale-to-zero billing and physical isolation both map well onto "thousands of short-lived, bursty workloads."
For conventional B2B SaaS with a few hundred steady-traffic tenants, the calculus is less obviously in AMP's favor. Shared-schema RLS with a well-audited policy set and decent connection pooling (PgBouncer, Supavisor, or similar) still works fine at that scale, and the operational surface of one well-tuned cluster is smaller than managing per-tenant provisioning even when that provisioning is automated.
What webhani checks before recommending a migration
Before suggesting a client move to a database-per-tenant or database-per-agent model on any platform, we look at:
- Wire compatibility depth. "PostgreSQL wire-compatible" covers a range of actual compatibility. We test the specific extensions, data types, and query patterns a client relies on (JSONB operators,
pg_trgm, full-text search, window functions) against the target platform before trusting marketing claims. - Migration tooling maturity. Yugabyte's included Voyager agent claims to handle migrations from Oracle, SQL Server, and MongoDB in addition to Postgres. Claimed support and production-tested support on a client's actual schema, including triggers, stored procedures, and constraint edge cases, are different things — we run a real migration against a staging copy before committing.
- Vendor lock-in surface. Standard Postgres wire protocol reduces lock-in at the query layer, but the operational agents (Architect, Perf Advisor, Nexus) and the billing model are Yugabyte-specific. We separate "what would it cost to leave" from "what would it cost to adopt" as two different questions.
- Vector and graph query needs. If a client's agent workloads genuinely need vector search or graph traversal alongside relational queries, a platform that supports both inside the same wire-compatible database avoids running a second specialized store (pgvector on a separate instance, a bolted-on graph layer) — that's a real simplification, not a marketing checkbox.
- Growth path out of serverless. The claim that workloads move from serverless to a dedicated tier without a rewrite or connection-string change is the kind of promise that needs a load test, not a read of the docs, before a client depends on it for a launch-day traffic spike.
Summary
AMP's core idea — physical isolation per tenant or agent, billed only for compute actually used — directly addresses two real pain points in multi-tenant Postgres architectures: RLS policy risk in shared schemas, and the fixed-cost floor of running many small dedicated instances. It's a genuinely good fit for agent-heavy architectures with thousands of bursty, often-idle workloads. For steady-traffic B2B SaaS at moderate tenant counts, shared-schema RLS with solid connection pooling remains a reasonable default, and the migration decision should hinge on tested wire compatibility, proven migration tooling on your actual schema, and an honest accounting of what's genuinely portable versus what ties you to one vendor.
References: YugabyteDB AMP, The Data Backbone for Thousands of Agents (Yugabyte), YugabyteDB Scales Agentic Postgres (The New Stack)