NVIDIA Adds an Ontology Layer to text-to-SQL, but Who Do the Certifiers Answer To?

The quietest error in text-to-SQL is when the SQL runs but the numbers are wrong. A database has a column like extendedprice, and the agent has to guess whether it means revenue. Within the same company, two systems may define revenue differently. NVIDIA has open-sourced Auto Ontology, aiming to add this layer of business meaning first, then let agents write queries.

In his tweet, Akshay Pachaar framed the release as fixing the biggest problem in text-to-SQL. The GitHub documentation is more restrained, describing it as reliability gates agentic analytics: a revenue metric can be answered ever so quickly, but if the number is wrong, it is worthless. This difference is worth remembering. The product addresses the reliability entry point; it does not adjudicate business definitions on behalf of the company.

What it actually stores

Auto Ontology stores the ontology in Postgres and embeddings in pgvector. It contains three types of definitions:

• terms: business concepts such as Customer, Order, and Revenue, with descriptions and synonyms, mapped to specific columns.
• SQL attributes: reviewed SQL expressions such as margin or rolling total. Agents reuse these expressions to ensure the same metric is calculated the same way every time.
• relationships: how tables join, including bridge tables, inferred from keys and the data itself.

Generation and certification

The ingestion service first reads the source database, profiles columns, and samples values; extracts terms table by table and maps them to columns; infers joins and bridge tables; mines SQL attributes from historical queries; and writes the first version of the ontology. People edit descriptions and expressions and certify them in the UI or API. In NVIDIA's Wide World Importers example, one compilation produces 31 terms. Selecting Order shows its description, related terms, mapped columns, and SQL attributes.

What happens at query time

The agent first classifies the question and extracts entities; uses embeddings to find candidate terms, columns, and SQL attributes; writes SQL; checks filter values against real data; fixes it if it fails; and after execution returns the answer, the SQL, and the steps. For questions the data cannot support, it says so plainly. In the demo, when asked about ad spend, the sales database has no ad data, and the agent replies: I can find revenue for this product, but there is no ad spend, so I cannot calculate ROAS; would you like to switch to June 2015 revenue, or connect to another data source? This behavior is more useful than getting a few more SQL queries right. Making up a number is easy; admitting there is no data is hard.

Architecturally, the ingestion service compiles the ontology, and agents connect through MCP, CLI, or REST API. It supports ten engines, including Postgres, Snowflake, Databricks, and DuckDB; it uses Nemotron by default and can also be configured with OpenAI-compatible endpoints; the license is Apache 2.0. GitHub currently does not accept external PRs; integration requests and bugs can be filed as issues. Repository: https://github.com/NVIDIA/auto-ontology

This idea of putting schema first is not new. In another article, Akshay Pachaar wrote about the same kind of problem with agent memory. Vector stores save facts as chunks and retrieve by similarity; once a query needs to connect facts across chunks, they fall apart. Knowledge graphs traverse nodes and edges, but most frameworks hand the extraction stage to an LLM, letting the model decide entity types, relationship labels, and attributes, and the result is very generic. Zep's approach uses Pydantic to define EntityModel and EdgeModel, telling the extraction model which entities and relationships exist in the domain and which fields each type has, and it also limits this to 10 entity types, 10 edge types, and 10 fields. Akshay's exact words were that schema defines the space of effective memory. Auto Ontology does the same thing, except the object shifts from agent memory to enterprise databases, and the schema is drafted from metadata and certified by humans. Reference: http://x.com/i/article/2058894488295378944

A few hard-to-avoid issues

Automatic drafting saves drafting time, but it cannot save you from certification. Several questions in the tweet replies are closer to real-world deployment than the release copy.

Who decides the definition. Alpha Batcher asks: if two teams both certify their own revenue column as correct, who has the final say? Auto Ontology's certify is a human action; the product does not resolve definitional authority for the organization. Certifiers, versions, and invalidation rules need to be spelled out in the process.

Will errors in historical queries be locked in. Caleb Jimmy and Asmir both ask: if the revenue definition in old queries was already wrong, does mining historical SQL attributes certify the error at scale? If the certification interface can show provenance, at least it can be reviewed; if not, that is trouble.

Finance changes the definition. Benjamin says that after a one-time certification, if finance changes the revenue calculation, the agent still answers confidently according to the old definition. Versioning and re-certification mechanisms are needed; otherwise certification becomes a one-time photo op.

Join cardinality. Ruslan, Huilong, and Paul Salmon all mention that joining 3 orders with 2 support tickets by customer_id produces 6 rows, and SUM(order_total) doubles. The SQL is valid; the number is wrong. Certification tests need to include refunded orders, multi-line orders, and one-to-many joins. Qyravex also points out that in TPC-H, revenue is extendedprice * (1 - discount), so mapping revenue directly to a column would be wrong. The certification step must be able to review formulas, not just column mappings.

These points are not meant to mark Auto Ontology down. They show that it moves the problem from 'can the agent write SQL' to 'does the company have anyone who can certify business definitions.' The former depends on model progress; the latter depends on the organization. NVIDIA's release can accelerate the first step, but humans still have to carry the second.

If you want to try it, do not roll it out across the whole database right away. Pick one highly disputed metric, such as revenue or active customer, write the terms, SQL expressions, join paths, and certifiers clearly, and then let the agent run. Put a refunded order and a multi-line order in the test data, specifically to see whether joins cause double-counting. It supports MCP, so it can connect to Cursor or Claude Desktop, or use REST. The default model can be changed, and the license is permissive. The repository is at https://github.com/NVIDIA/auto-ontology

The valuable part of automatic ontology may not be the automatic part, but turning the informal definitions scattered across each team's SQL into objects that can be discussed, certified, and versioned. As for who has the final say, the tool cannot answer that.