NVIDIA Auto Ontology: The Free Open-Source Layer That Grounds AI Agents in Your Data

Ask an AI agent for last quarter's revenue and it will answer fast, in confident language, with a chart. The problem is that the number can be wrong, and nothing in the answer tells you. The agent guessed what "revenue" means, picked the columns that looked right, and joined tables that should never have met. NVIDIA's answer to that problem is Auto Ontology, an open-source layer that sits between the agent and the database and hands it certified definitions instead of raw table names. The project has been public since April, but it found its audience this week: it surfaced on Hacker News on November 3 with about 1,100 stars, and by the morning of November 5 it had 6,135 stars and 484 forks and sat at number one on GitHub's daily trending list. This article explains what it does, what it costs to run, and the security catch in its default setup.

Auto Ontology is part of NVIDIA's Agent Knowledge Foundation, announced on October 21, 2026 at GTC Berlin as one piece of a wider open toolkit for grounding agents in company data. The repository describes the problem in one sentence: "a revenue metric answered faster is worth nothing if the number is wrong." The tool builds a semantic, graph-based layer from enterprise database metadata, reconciles definitions across systems, and exposes that layer to any agent harness through MCP, a command line, and an API. It is distributed under the Apache 2.0 license, so the code itself costs nothing. The bill comes later, from the model calls.

What Auto Ontology actually is

A semantic layer is a shared dictionary for a database. It records that "revenue" means the sum of extended prices on invoice lines, not the gross amount on an order header, and that a customer in the sales system is the same entity as a customer in the warehouse system. Without one, every agent that touches the database reinvents those definitions, usually badly. Auto Ontology generates a first draft of that dictionary from metadata, then asks people to certify it.

The README frames the work as five verbs. Discover means generating ontologies from metadata and connecting existing semantic models. Ground means giving agents trusted business meaning for metrics, entities, and relationships. Validate means checking generated queries against certified definitions and lineage. Expose means serving the context through MCP, CLI, and API. Learn means folding certified corrections and usage back into the ontology, so the shared context improves with every question. The tool is designed to complement semantic models a company already owns, and it can import and export definitions as Apache Ossie YAML, the open standard for exchanging semantic models.

That framing matters because the alternative is what most teams do today: let the agent read the schema and hope. Schema names lie. A column called "amount" can hold a net figure in one table and a gross figure in another, and no amount of prompt engineering fixes a join the model chose for the wrong reason. Auto Ontology moves the definition out of the prompt and into a versioned, certifiable layer the agent has to consult. Google's Data Agent Kit takes a similar MCP-first approach for its own data cloud services, but it is a vendor toolkit, not a layer you certify yourself.

How it works: generate, certify, answer

Auto Ontology works in three stages. First it generates an ontology. The ingestion service reads source databases, extracts schemas, profiles columns, and samples values into a catalog. It then extracts business terms table by table, maps each term to the columns that hold it, infers joins between tables including bridge tables, and suggests SQL attributes from query history. The result is stored in Postgres with embeddings in pgvector. In the README's worked example, one compilation of Microsoft's Wide World Importers sample database produced 31 terms.

Then people certify the draft. A data owner tests it with real questions in the web chat, or through the MCP tools, refines terms, descriptions, and SQL attributes in the UI or through the API, and certifies them once they are correct. Certification is the load-bearing step. An uncertified ontology is just a machine-generated guess with better formatting, and NVIDIA's own documentation frames the output as a starting ontology that business experts still test, refine, and certify.

Then the agent answers from it. For each question, the agent classifies the intent, extracts the entities named, retrieves candidate terms, columns, and SQL attributes by embedding search, writes SQL from those candidates, checks the filter values and the query against the database, repairs the SQL when a check fails, and runs it. The answer comes back with its SQL and the steps that produced it. The README's example asks for revenue for one product in one state in one month, and the answer is $588.80 from 3 invoice lines, with the full SQL shown so a human can check it against the source.

Just as useful is what happens when the data cannot answer the question. Asked for return on ad spend for the same product, the agent checks coverage first, finds no term covers ad spend, and says so instead of inventing a number. It offers the revenue figure instead, or asks whether ad spend is tracked in another source it should connect. A tool that refuses to answer is worth more than a tool that answers wrong with confidence.

What your agent gets: nine read-only MCP tools

The MCP server gives any MCP client nine read-only tools over the ontology. Each user signs in through Auto Ontology, and every call runs with that user's permissions. The tools are:

Results from ask_question are capped at 100 rows. There is deliberately no tool for browsing raw schemas, so agents reach data through the semantic layer rather than around it. The same deployment also exposes a REST API and a command-line interface, and the published OpenAPI specification lists 87 operations. Sign-in runs through OAuth, and the MCP server is read-only by design, so a connected agent can ask questions but cannot write to your database through it.

What it plugs into, and what it runs on

Auto Ontology connects to ten database engines: PostgreSQL, MySQL, Databricks, Snowflake, ClickHouse, Trino, Apache Kyuubi, HeavyDB, DuckDB, and SQLite. Connections are added in the web UI or listed in an environment variable. DuckDB and SQLite are connection-string only.

The stack itself is five services. A Next.js 16 frontend handles the web UI and authentication on port 3000. A FastAPI backend runs chat and catalog APIs on port 3001. An ingestion worker writes embeddings on port 3002. The MCP server runs on port 3003. Postgres 17 with pgvector stores the catalog, the ontology, and the vectors on port 5432. Deployment is Docker Compose for a local stack or a Helm chart for Kubernetes, and NVIDIA also publishes the backend as an NGC container.

Inference runs through NVIDIA NIM endpoints by default, using an API key from build.nvidia.com, or through self-hosted NIMs. Each model role is configured by a triplet of endpoint, API key, and model name, and any OpenAI-compatible endpoint can be swapped in. The defaults in the README are:

One small documentation wrinkle: the README's quickstart section names a different reranker, nvidia/llama-nemotron-rerank-vl-1b-v2, as the default in the environment file. The models table above is the more detailed reference, but check the environment file at install time rather than trusting either page alone. There is also an optional predictions path: set a KumoRFM API key and the agent routes predictive questions to KumoRFM, which uploads the connected tables to that hosted service, capped at 20 tables by default. Review what that sends before enabling it.

What it costs

The code is free under Apache 2.0, and there is no subscription, no seat fee, and no published price list for the tool itself. The real cost is inference, billed per token by whichever model endpoint you configure, plus the infrastructure you run it on.

For the default model, Nemotron 3.5 Lightning 30B, third-party catalogues list roughly $0.07 per million input tokens and $0.20 per million output tokens, with some variation by provider. At November 5, 2026 market rates, that is about £0.05 and C$0.10 per million input tokens, and about £0.15 and C$0.28 per million output tokens. Those are approximations, and NVIDIA's own API catalog is the rate that counts at sign-up, so check build.nvidia.com before budgeting. The model is open-weight, so self-hosting through NIM or another host is an alternative to paying per token, and any OpenAI-compatible endpoint can be substituted, which means the per-token price follows the provider you choose rather than the tool. If that per-token math feels unfamiliar, KT's Token Factory puts 73 models on one bill and shows how the same pricing model looks at marketplace scale.

No per-token rates are published in the repository for the embedding and reranking models, so the honest way to budget is to treat the reasoning model as the main cost and expect the other two to add a smaller, unquoted amount on top. The ontology compilation step, which reads schemas and samples values across every connected source, is the heaviest single job. The other cost is the stack itself: a host for Postgres, Docker, and the five services, which is yours whether the tool is free or not.

Auto Ontology vs the other semantic layers

Auto Ontology is not the first semantic layer, and the established options take different approaches. Wren AI generates context from metadata with agent assistance. Cube defines metrics in code and serves them over APIs. dbt MetricFlow defines metrics in a dbt project. Auto Ontology's difference is that the layer is generated from metadata, certified by people, and served to agents over MCP.

The comparison matters less than the fit. If your metrics already live in dbt, MetricFlow is the shorter path. If you want an agent to use a semantic model without hand-writing definitions, Auto Ontology and Wren AI are the closer match, and Auto Ontology is the one with certification and answerability checks built into the workflow.

Four catches to know before you connect a database

The 90 percent figure is NVIDIA's own. Coverage of the launch repeats the claim that Auto Ontology cuts ontology creation time by 90 percent in NVIDIA's testing. The company has not published the test scale, the human review effort, or the evaluation methodology behind that number. Treat it as a vendor claim about its own workflow, not a measured result you can plan around.

There are no published accuracy scores. NVIDIA ships a separate evaluation harness, auto-ontology-eval, which runs a schema-only control against the ontology-grounded agent on the BIRD benchmark, 1,534 questions across 11 databases in the full development set and 500 in the mini set, plus FDABench-Lite with 169 questions and a 100-question BEAVER sample. Scoring is deterministic execution match with no LLM judge, which is a serious design choice. But the repository ships the harness, not results. No text-to-SQL accuracy score for Auto Ontology has been published anywhere, so the only honest way to judge it is to run the harness against your own schema.

Database passwords sit unencrypted unless you switch on Vault. This is the catch that matters most, and it comes from NVIDIA's own documentation rather than a third-party audit. HashiCorp Vault is optional and off by default. Without it, the full connection object, password included, is serialized to JSON and stored unencrypted on the catalog's database row in Postgres. A partial Vault configuration is ignored with a warning and credentials fall back to plaintext storage. The README also warns that ports 3001 and 3002, the backend and ingestion services, have no authentication of their own and should stay on a private network. None of this makes the tool unsafe to use, but it does mean the default setup is not a production setup. Enable Vault, or at least a dedicated Postgres, before connecting anything real.

NVIDIA is not accepting outside contributions. The README states plainly that the project is currently not accepting external contributions, and the repository carries 48 open issues with no public pull-request path. If you find a bug, you can file an issue, but you cannot fix it upstream yourself. For a tool that sits between agents and production data, that single-maintainer shape is worth knowing before you build on it.

Who should try it, and who should wait

Auto Ontology fits data teams whose definitions are the bottleneck: a warehouse where "revenue" means three different things in three different dashboards, a team that has watched agents confidently join the wrong tables, or an agent builder who needs a governed way to give a coding agent database access. It also fits shops already running Postgres, Snowflake, or Databricks, since those are first-class sources.

Wait if you need audited accuracy numbers before adopting a tool, because none exist yet. Wait if nobody on your team can certify the terms, because an uncertified ontology is the same guessing with extra steps. And wait if you cannot run the Vault setup or isolate the backend ports, because the default configuration stores credentials in plaintext and trusts its internal network. The tool is free and the setup is a Docker Compose file, but the certification and the security hardening are the actual work. The agent side of the story is moving fast too: AWS Infinity runs 75,000 agents with zero compute while they wait, and the agents that need a semantic layer will only get more numerous from here.

Pro tips and common mistakes

• Enable Vault before you connect a production database, not after. The fallback to plaintext storage is silent enough to miss.
• Keep ports 3001 and 3002 on a private network. The README says so directly, and the ingestion endpoints have no authentication of their own.
• Certify a small set of terms first, then expand. Ten certified definitions that agents actually use beat a hundred generated ones nobody checked.
• Run the auto-ontology-eval harness against your own schema before trusting the answers. The BIRD datasets prove the harness works, not that the tool works on your data.
• Start with the sample database. The quickstart uses Microsoft's Wide World Importers, and it is the fastest way to see the generate-certify-answer loop before pointing the tool at real tables.
• Check the reranker default in the environment file. The README names two different rerankers in two places, and the one that actually runs is the one in your configuration.
• Do not read the star count as production proof. About 5,000 stars in two days measures attention, and the repository is about six months old with no published accuracy results.

Frequently asked questions

Is NVIDIA Auto Ontology really free?

The code is free under the Apache 2.0 license, with no subscription or seat fee. You pay for the model calls it makes through NVIDIA NIM or another endpoint, roughly $0.07 per million input tokens and $0.20 per million output tokens for the default model on third-party catalogues, plus the server you run it on.

Does it work with my database?

It connects to PostgreSQL, MySQL, Databricks, Snowflake, ClickHouse, Trino, Apache Kyuubi, HeavyDB, DuckDB, and SQLite. If your warehouse is on that list, the connector exists. Anything else needs to go through an OpenAI-compatible endpoint or a different tool.

How accurate is the SQL it writes?

Unknown in public terms. NVIDIA publishes an evaluation harness but no accuracy results, so there is no published text-to-SQL score to quote. The design helps, because the agent writes SQL from certified definitions and validates the query before running it, but the only way to know the accuracy on your data is to run the harness yourself.

Can it replace dbt MetricFlow or Wren AI?

It can complement them rather than replace them. If your metrics already live in dbt, MetricFlow is the shorter path. Auto Ontology fits teams that want a generated, certifiable layer served to agents over MCP, and it can import and export definitions as Apache Ossie YAML, so the models are not locked inside it.

Is it safe to point at a production database?

Not with the default settings. Without Vault, database passwords are stored unencrypted in Postgres, and the backend and ingestion services have no authentication of their own. Enable Vault, keep the internal ports on a private network, and connect a read-only database user before letting agents near production data.

What does the 90 percent faster claim actually mean?

It is NVIDIA's own figure for ontology creation time in its internal testing, repeated in launch coverage. The company has not published the test scale, the human review effort, or the methodology, so it is a vendor claim, not an independent measurement.

Sources

• NVIDIA Auto Ontology repository and README — Apache 2.0, 6,135 stars and 484 forks verified November 5, 2026; model defaults, MCP tools, sources, and worked examples
• Auto Ontology connections documentation — plaintext credential storage without Vault, Vault configuration requirements
• NVIDIA auto-ontology-eval repository — BIRD, FDABench-Lite, and BEAVER harness, no published results
• MarkTechPost, November 2, 2026 — 90 percent ontology creation claim, nine MCP tools, 100-row cap, comparison with Wren AI, Cube, and dbt MetricFlow
• NVIDIA blog, October 21, 2026 — Agent Knowledge Foundation announcement at GTC Berlin
• ExplainX, November 2026 — about 1,100 stars on November 3, Hacker News appearance, model defaults
• NVIDIA API catalog (build.nvidia.com) — source of the nvapi key for the default NIM models