NVIDIA Auto Ontology vs QueryPanel: Two Answers to the

NVIDIA's Auto Ontology and QueryPanel both answer plain-English questions by writing SQL from context about your data. They solve different products around that shared core. This article explains what each one does and who should pick which.

Short answer: Auto Ontology is an open-source, self-hosted context layer. It builds an ontology from your database metadata, lets people certify it, and serves it to any agent through MCP, a CLI and an API. QueryPanel is a hosted embedded analytics product for B2B SaaS teams. Its text-to-SQL pipeline is built around tenant isolation and customer-facing dashboards. If you need a governed context layer that many internal agents can share, look at Auto Ontology. If you need to put AI analytics in front of your own customers, safely and per tenant, that's what QueryPanel is built for.

Key takeaways

Both tools agree on the core point: text-to-SQL accuracy depends on the context the model gets, more than on the model itself.
Auto Ontology generates that context automatically: business terms, reusable SQL attributes and join relationships. People then review and certify it.
In QueryPanel, people write most of that context: schema annotations, a glossary and gold SQL examples. QueryPanel adds join hints derived from the schema.
Auto Ontology checks filter values against the live database before running a query. QueryPanel checks that the tables and columns in generated SQL exist and that every tenant table is filtered by tenant. It repairs filter values after a query comes back empty.
QueryPanel's distinctive parts are multi-tenancy, a headless SDK that runs SQL in your own backend, and embeddable dashboards. Auto Ontology does not target those.

What NVIDIA Auto Ontology is

Auto Ontology is an Apache-2.0 project from NVIDIA. It runs as a set of services: a Next.js web app, a FastAPI backend that uses LangChain, an ingestion service, an MCP server, and Postgres with pgvector for the catalog, ontology and embeddings. By default it uses NVIDIA NIM models for reasoning, embeddings and reranking. You deploy it yourself, with Docker Compose or a Helm chart.

Its ontology holds three kinds of definition:

Terms: business concepts such as Customer or Invoice Line, with descriptions and synonyms, mapped to the columns that hold them.
SQL attributes: reviewed SQL expressions under a term, such as a margin or a rolling total. The agent reuses them, so every answer computes a measure the same way.
Relationships: how tables join, including bridge tables, inferred from keys and from the data.

The workflow has three stages:

Generate. The ingestion service reads schemas, profiles columns, samples values, extracts terms table by table, infers relationships, and suggests SQL attributes from query history.
Certify. People test the draft with real questions, refine terms and attributes, and mark them as certified.
Answer. For each question, the agent classifies intent, retrieves candidate terms and columns, writes SQL, checks filter values and joins against the database, repairs the SQL if a check fails, then runs it. It returns the answer with its SQL and the steps it took.

Over MCP it also offers a check_answerable tool. It reports whether the ontology covers a question at all, so an agent can ask the user to clarify instead of guessing. It connects to ten engines, including PostgreSQL, Snowflake, Databricks, ClickHouse and Trino. It also imports and exports models in Apache Ossie, an open format for exchanging semantic models.

This is a serious, well-structured piece of work. The certify step deserves particular credit: an ontology an AI drafts and nobody reviews is just another guess.

What QueryPanel is

QueryPanel is embedded analytics for B2B SaaS. Teams use it to give their own customers AI-generated charts and dashboards inside their product, with each customer seeing only their own data. It ships as:

a React SDK for an embedded dashboard workspace with a built-in AI assistant;
a headless Node SDK for teams that build their own UI and want SQL to run in their own backend;
an admin app where teams connect data sources, annotate schemas and build dashboards;
an MCP server for admin workflows, with tools like generate_sql, search_schema, annotate_schema, train_glossary, train_gold_sql, create_dashboard and create_alert.

QueryPanel's text-to-SQL path works like this:

Ingest. The schema is synced (through the Node SDK or the admin app) and split into table and column chunks. Human-written context is attached to those chunks: schema annotations, glossary entries and gold SQL examples.
Retrieve. For each question, a hybrid search combines vector similarity with full-text search over those chunks.
Generate. The model returns structured output: the SQL, its bind parameters and a plain-language rationale.
Check. A reflection step reviews the SQL for semantic errors. A grounding check confirms every table and column the SQL references exists. If they don't, QueryPanel tells the user "I couldn't find X in your data" and suggests related fields, instead of returning SQL.
Enforce tenant isolation. When a workspace enforces tenant isolation, a deterministic check requires every tenant table in the SQL to be filtered on the tenant column with a bind parameter. A literal tenant ID is rejected.
Execute. In the headless path, SQL runs through a database adapter in the customer's own backend (Postgres, ClickHouse and BigQuery adapters ship today). The database credentials never reach QueryPanel.

QueryPanel also has a dashboard agent that explores the schema and runs SQL step by step. And it derives join hints from the schema, including polymorphic "type + id" columns that point to different tables depending on the type.

Where they overlap

	Auto Ontology	QueryPanel
Question → SQL	Multi-step agent with intent, retrieval, generation, value and join checks, repair	Intent, hybrid retrieval, generation, reflection, grounding and tenant checks
Context store	Postgres + pgvector	Postgres (Supabase) with vector + full-text search
Business meaning	Terms and synonyms, generated then certified	Annotations, glossary and gold SQL, written by people
Joins	Relationships inferred and stored	Join hints derived from the schema, including polymorphic columns
Explainability	Answer returned with SQL and steps	SQL returned with a plain-language rationale
Agent access	MCP (read-only ontology tools + `ask_question`), CLI, REST	MCP server for admin workflows, Node SDK, REST API

Both projects reached the same conclusion: a model writing SQL from raw table names alone is not reliable enough. Both put a layer of business meaning between the question and the database, and both show their work.

Where they differ

How context is built. This is the biggest difference. Auto Ontology generates a first draft of the ontology from metadata, profiling and query history. In QueryPanel, people write the context through annotations, glossary entries and gold SQL. On a large schema, generating a draft and then reviewing it can save a lot of manual work. Writing context by hand gives precise control, but someone has to do it.

Reusable measures. Auto Ontology's SQL attributes are certified formulas that the agent reuses. QueryPanel's gold SQL examples serve a similar purpose, but they're whole example queries the model learns from, not building blocks it composes.

Value checks. Auto Ontology checks filter values, such as a product name or a state, against the actual data before running the query, and repairs queries that return nothing. QueryPanel checks structure (tables, columns, tenant filters) before running. It repairs filter values only after a query comes back empty:

Dashboard agent: QueryPanel looks up stored values close to the one the user typed. These lookups are read-only and scoped to the tenant. The agent then swaps in the closest value and runs the query once more.
Headless Node SDK: an opt-in option (retryOnEmptyResult) reports the empty result back and regenerates the SQL. QueryPanel never sees the data values.

We built both after studying Auto Ontology's approach.

Tenancy. QueryPanel is built for SaaS products where many customers share one database or schema pattern. Tenant isolation is enforced on every query, and embed tokens carry the tenant. Auto Ontology has user authentication and role-based access, but per-tenant row isolation in a shared database is not its focus.

Where SQL runs. With QueryPanel's headless SDK, SQL executes in the customer's backend, and QueryPanel never holds database credentials. Auto Ontology connects to your databases directly from its own backend, with an option to store credentials in HashiCorp Vault.

What users see. QueryPanel's output is embeddable charts and dashboards that your customers use inside your product. Auto Ontology's output is answers and context for agents, plus a web UI for chat, catalog and ontology management.

Deployment. Auto Ontology is open source and self-hosted. QueryPanel is a hosted service.

Who each one is for

Choose Auto Ontology if:

you want one governed context layer that several internal agents and tools can share;
you have many databases and want an AI-drafted ontology instead of writing definitions by hand;
you need certification and provenance for metric definitions;
you want to self-host, run on NVIDIA NIM models, or exchange models in Ossie format.

Choose QueryPanel if:

you run a B2B SaaS product and want AI analytics in front of your own customers;
each customer must see only their own data, enforced on every query;
database credentials and raw rows must stay in your backend;
you want embeddable dashboards and charts, not only answers to questions.

The two aren't mutually exclusive. A team could use Auto Ontology to draft and certify business definitions, then bring those definitions into a product that serves analytics to customers.

What we're taking from it

Auto Ontology makes a strong case for three ideas:

Repairing wrong filter values. We shipped the after-the-fact version described above.
An explicit "can this be answered?" check. QueryPanel's grounding check covers part of this already.
Drafting terms and relationships automatically at ingest, for people to review.

The last two are evaluations, not shipped features. We'll write about them if and when they land.

NVIDIA Auto Ontology vs QueryPanel: Two Answers to the Text-to-SQL Context Problem