YugabyteDB AMP: what 'one Postgres per tenant' actually fixes. webhani · 2026-08-19 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. 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. 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: 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. 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. Before suggesting a client move to a database-per-tenant or database-per-agent model on any platform, webhani inc. 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. 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.

The Weekly Edge: RDF inference, Yugabyte MAGE, visualization with Apache AGE. Happy Thursday! gdotv Ltd is back at it, once again keeping you updated on the latest graph news. Headlines this week: * "I am once again asking you to follow the rules." Pieter Colpaert illustrates how to make the most of N3 rules along with a number of runnable demos. * You get a database, and you get a database (etc. etc.): A new version of Yugabyte introduces per-agent Postgres databases, along with other features like Yugabyte MAGE with graph functionality. * Visualization for the AGEs: Christian Miles talks through visualization with Apache AGE. * Schema without the scheming: TRACE-KG illustrates a framework that builds knowledge graphs and schema without a pre-defined ontology. * Who said what now? Researchers in Bologna have devised a DEC framework to handle concepts of provenance. /* * It's time to level up your graph game: * Query, explore, edit, and visualize your connected data with the gdotv graph IDE * Try out the free dev tier or upgrade to a 1-month, no-fuss free trial. */ If you're new here, the Weekly Edge is your weekly tl;dr of graph technology news curated by the team at gdotv, giving you all the reads, repos, vids, and walkthroughs worth exploring from the past seven-ish days (or so). [Tutorial]: stop hand-aligning your ontologies. Let the rules do it. Anyone who's worked with Linked Data has heard the pitch that it lets you align data automatically, then watched everyone quietly go back to spreadsheets and manual mappings. Pieter Colpaert opens with exactly this gripe. A decade-old conversation where a Transmodel Ontology lead asked him why she'd bother with RDF when the Linked Data crowd was still aligning everything by hand. His answer, post-SHACL and post-agentic-AI, is to stop writing rules about your domain and start writing them about the ontology language itself. Instead of a separate rule for HydrogenBus, CargoBike and ElectricFerry, you write generic N3 rules once against primitives like rdfs:subClassOf, and each project just annotates its own vocabulary. From there he layers OWL 2 RL, SKOS and SHACL together - and reframes SHACL not just as a gatekeeper but as another flavour of inferencing, where the derived knowledge is the validation report itself. The really clever bit is using shapes as optimization hints for stream processing: work out the reasoning plan once, then apply a compact runtime to every message that matches the shape. Best of all, the whole post is stuffed with editable in-page demos powered by his new rdfjs-inference-engine (now on npm) and Eyeling. [News]: A Postgres for every agent (yes, every single one). Yugabyte has decided that if Gartner is right and the average Fortune 500 will be running 150,000-odd AI agents in a couple of years, then those agents are going to need somewhere to put their data. Their answer is YugabyteDB AMP (Agentic Multitenant Postgres), launched alongside YugabyteDB 2026.1. The pitch is "the growth cliff", the familiar pattern where a prototype runs on cheap serverless Postgres with a vector store bolted on, then ships, scales, and triggers a painful migration crisis. AMP's fix is scale-to-zero serverless multitenancy where each agent gets its own real, isolated Postgres database, and every lifecycle operation (provisioning, branching, scaling, migration, teardown) is exposed over MCP rather than just a read endpoint. For gdotv Ltd graph folks, the interesting line item is YugabyteDB MAGE, a multi-tenant graph engine (in technical preview) sitting alongside native vector search and in-database RAG. The whole strategy is convergence: fold the primary database, vector store, graph layer and pipeline glue into one system instead of stitching five together. Whether agents really want their own database is a debate for another newsletter, but the graph-on-relational momentum is hard to ignore. [Talk]: querying & visualizing graphs in Postgres with Apache AGE. In his POSETTE 2026 talk, Christian Miles walks through what works and what breaks when you try to visualize Apache AGE query results, explaining that layouts obscure rather than reveal, node-link diagrams that turn to spaghetti at modest scale, and interaction patterns that fall apart when graphs get dense. The framing is one gdotv Ltd'd happily co-sign: AGE lets you store graphs inside Postgres and embed Cypher in SQL, but the usual database tooling was never built to actually show you a graph while graph results need visualization designed for connected data, not approaches that flatten everything back into rows. Drawing on fifteen years of building graph visualization tools, Miles covers when to reach for force-directed layouts versus layered or topology-aware ones. If you're running AGE and squinting at result tables, this one's for you. (And naturally, if you'd like to connect a proper IDE to your AGE instance, you know where gdotv Ltd is.) [Paper]: TRACE-KG: build the graph and the schema, no ontology required. Knowledge graph construction usually forces an awkward choice. Ontology-driven pipelines give you consistent typing but cost a fortune in schema design and maintenance; schema-free extraction is cheap but produces fragmented graphs where the same entity shows up under five names and near-duplicate predicates proliferate. TRACE-KG, out of Arizona State, tries to have it both ways. It's a multimodal framework that constructs a context-enriched knowledge graph together with an induced schema (no predefined ontology) while keeping full traceability back to the source text. Two ideas stand out. First, conditional relations: rather than flattening everything into unconditional triples, it attaches structured qualifiers capturing when and under what conditions a relation holds. Second, auditable construction: the LLM never edits the graph directly. It emits a JSON array of actions like MERGEENTITIES that deterministic validators then execute and log. The evaluation has a nice bit of methodological spine, too. They argue raw retrieval accuracy is misleading and introduce metrics that penalise "leakage" (copying long text spans into entity strings) and structural fragmentation. On those, TRACE-KG holds high accuracy with dramatically lower leakage than the baselines. A good read if you're building text-to-graph pipelines and tired of the schema/no-schema dichotomy. [Paper]: "according to..." Is doing more work than your graph admits. A wonderfully heady note to end on. Vitali and Pasqual (Bologna) point out that huge swathes of real knowledge graphs aren't facts at all! They're capta: claims, interpretations and hypotheses, like who painted the Salvator Mundi, where provenance isn't optional metadata but the whole reason a statement is even in the graph. The problem: today's provenance models (PROV-O, Wikidata's rankings, plain reification) deliberately stay semantically neutral. Attaching a source isn't supposed to change a statement's truth conditions. But that means a graph holding two scholars who disagree either collapses into a contradiction or loses the disagreement entirely, when the divergence is itself meaningful. Their DEC framework reads provenance predicates as signals of epistemic stance ("wrote" vs "believed" vs "supposed") and groups statements with similar provenance into cognitive worlds, drawing on doxastic, epistemic and conjectural modal logics. That lets a graph reason over attributed claims, and explicitly surface disagreements and "delusions," without everything dissolving into inconsistency, and it sidesteps the old reasoning headaches like the Superman paradox. (The "Superman paradox" refering to a sticky region of semantics: without careful reasoning, the statements "Lois Lane believes Superman can fly" and "Superman is Clark Kent" could easily erroneously imply "Lois Lane believes Clark Kent can fly".) The lovely practical kicker: there's a working prototype reasoner built as an Apache Jena Fuseki dataset module, and it works the same across named graphs, RDF-star quoted triples and classic reification. Pairs neatly with the TRACE-KG provenance story above. And be aware! Two papers, same week, both insisting that where a statement came from deserves to be a first-class citizen. Got a graph DB? Get an IDE! gdotv takes no more than a couple of minutes to setup, and offers a free, no-fuss 1 month trial. P.S. Postgres 19 is on the horizon, and looks like it might bring a few graph-ish updates along for the ride. More from the Weekly Edge on that next time! P.P.S. If you didn't catch the latest Graph Pulse, gdotv checked in with PuppyGraph CEO Weimo Liu on just why graphs are so popular right now! P.P.P.S. Got an item to nominate for the next edition of the Weekly Edge? Hit me up at [email protected] or hit reply!

Yugabyte has launched Meko, an agent-native data infrastructure designed for multi-agent AI systems. The platform addresses a critical challenge in enterprise AI: providing agents with persistent, shared memory and knowledge that enables collective learning across systems. Meko unifies memory, knowledge, conversation history and observability into a single layer, replacing fragmented stacks of databases, vector stores and caches. Built on YugabyteDB, it supports SQL, NoSQL, vector, time-series and graph queries within a single system. The platform introduces Datapacks, portable multi-tenant data stores that allow agents to share learnings while preserving reasoning context and decision traces. Its serverless architecture optimises costs for bursty agentic workloads and provides complete audit trails for regulatory compliance, including EU AI Act requirements. Meko is available as a fully managed service and will become open source.