All the user's data.
One interface. No migrations.
UDB is the data plane agents work against: runtime-defined tables with zero DDL, plus a unified adapter layer into the user's existing Postgres, MySQL, HTTP APIs, and file storage — queryable in natural language, with semantic mappings that learn from every query.
Read the docsAgents need a place to keep state. Migrating your database isn't it.
An agent that reasons but can't persist anything just re-derives the same facts every turn. Give it a raw connection to your production database and you've handed a language model unsupervised write access to the system of record. Give it a vector store instead and you've traded structure for approximate recall. UDB is the option in between: tables it can define at request time with zero DDL, plus governed adapters into the systems you already run — so agents get somewhere to work without your data ever moving.
Runtime-defined tables
Agents create and evolve tables at request time — no migration file, no deploy, no schema review. Every table is tenant-scoped from the first write.
Adapters into what you run
Postgres, MySQL, HTTP APIs, and file storage connect through governed adapters. Nothing is copied or replicated — UDB reads and writes through the connection you configure.
Natural language query
Ask a question in plain language; UDB resolves it against known tables and adapters and returns typed results — not a SQL string for the agent to get wrong.
Semantic mappings that learn
Every resolved query reinforces the mapping between intent and schema, so the next similar question resolves faster and more precisely than the last.
One interface, many backends
Runtime tables and external adapters answer through the same query surface. The agent doesn't need to know — or care — which backend holds the answer.
Tenant isolation by default
Every table, adapter connection, and cached mapping is scoped to an account. Cross-tenant access is impossible by construction, not by convention.
One query interface. Every backend behind it resolves the same way.
THE RESOLUTION LOOP
Ask — a query arrives in natural language — from an agent mid-task or a direct call from your app. No SQL, no table name required.
Resolve — semantic mapping checks it against known runtime tables and adapter schemas, using every prior query that has resolved a similar shape before.
Route — the match determines the backend: a runtime table, or an adapter into Postgres, MySQL, an HTTP API, or file storage.
Fetch — the backend is queried directly — nothing is copied into UDB first — and results normalize into one typed shape.
Return — results come back through the single interface, regardless of which backend actually answered.
Reinforce — the mapping strengthens: the next query shaped like this one resolves faster, with less ambiguity.
Define tables, query in natural language, connect adapters.
An access layer, not a copy of your data.
Zero-DDL by design — runtime tables are created and altered through the API, never a migration file — schema changes ship the moment an agent needs them.
Tenant isolation, always — every table, adapter connection, and cached mapping is account-scoped; cross-tenant access is impossible by construction.
Your data doesn't move — adapters query Postgres, MySQL, HTTP APIs, and file storage live, in place — UDB holds mappings and cached results, never a copy of the system of record.
Adapters fail loud, not silent — connection health is monitored per adapter; a broken credential or unreachable host surfaces as an error, not a silently stale answer.
Mappings are inspectable — every learned semantic mapping is queryable and correctable — query resolution is never a black box.
Retention follows the source — runtime tables and cached results follow your configured retention policy; adapters never persist a copy of source-system data beyond the life of a query.
What one query interface over many backends actually looks like.
An agent needs to track escalation_owner per account mid-conversation. It defines the field and writes to it in the same turn — no ticket, no deploy.
"Which customers are past due and haven't opened the last email?" resolves to a join between a runtime table (email opens) and a Postgres adapter (invoices) — the agent never learns there were two backends.
A ten-year-old MySQL instance holding order history becomes queryable in natural language the day the adapter connects — no ORM, no export.
A folder of CSV exports in file storage answers the same way a table would — UDB indexes what's discoverable and treats it as a queryable source, not a document to summarize.
The first time an agent asks for "active enterprise accounts," resolution takes a beat while UDB checks schemas. The fiftieth time, it's a direct hit.
Give your agents a data plane, not a data migration.
Runtime tables, governed adapters, and a single interface over whatever you already run — UDB stays out of the way.