NVIDIA/auto-ontology

Treat this as a self-hosted stack for making one or more relational databases legible to an agent, not as a drop-in text-to-SQL library. A team that already asks an agent to answer revenue questions and keeps correcting wrong joins or conflicting metric definitions is the audience.

The problem

An analyst wants a yes-or-no revenue answer from a warehouse. Today that means pasting schemas and column descriptions into a prompt, watching the agent pick a plausible but wrong table, and checking the generated SQL by hand. Auto Ontology moves that context into a catalog built from enterprise metadata, so query generation starts from documented tables, meanings and definitions instead of raw DDL. The result is a visible data catalog and an agent-facing layer that returns SQL tied to those entries.

What's different

The core mechanism is an ontology layer stored in Postgres next to the catalog it describes. The project reconciles definitions across systems and exposes them through MCP, a CLI and an API, so an existing agent harness can consume the same context rather than embedding schema notes in prompts. Natural-language questions are translated to SQL and executed against connected sources, with NVIDIA NIM endpoints handling chat, entity extraction, embeddings and reranking. Because ingestion and querying must share the same embedding model, changing models later means reworking how documents were indexed, not only changing a setting.

The practical trade-off is architectural weight. This is a multi-service application: a Next.js frontend with Better Auth and Prisma, a FastAPI backend using LangChain, Postgres, pgAdmin, an ingestion service and a one-shot schema-migration job. You get a UI, role-based access and deployment charts, but you also take on credentials, database migrations and the lifecycle of several containers. The README positions it as complementing semantic models a customer already owns, so the plausible use is layering it over existing definitions rather than replacing them.

Who should try it

Good fit: a data or analytics team with three or more relational sources and an agent workflow where wrong metrics carry real cost. The catalog, authentication and MCP interface make sense when several people and agents need the same shared interpretation of tables and metrics. It is also a reasonable trial if you already run NVIDIA NIM or are willing to self-host those models and want an end-to-end example rather than individual parts.

Poor fit: a single-person project asking one question against one DuckDB file. The container stack and environment-file setup outweigh the benefit. Also a poor fit for anyone who wants an unopinionated Python library to embed in an existing service, since the documented path is the full application. Teams without an NVIDIA API key or self-hosted NIM deployment should check what the model configuration actually requires before counting this as an option.

Requirements and limitations

Docker with Compose v2 or a Kubernetes cluster is required, plus an NVIDIA API key for NIM and connection details for Databricks, Postgres, Snowflake or DuckDB sources. Two settings, AUTH_SECRET and APP_URL, are mandatory; leaving them unset breaks every page with a Better Auth default-secret error. Setup instructions live in the project README and deployment guide, with the full variable list in the environment template.

Ongoing upkeep matters more than initial setup. Connections added through the UI store credentials in plaintext in Postgres unless Vault is configured; with Vault, the database name is the lookup key and no separate reference field exists, so renaming a database affects how credentials are found. Embedding model consistency between ingest and query is another operational invariant. The project is Apache-2.0 but explicitly not accepting external contributions, so fixes depend on NVIDIA. Benchmarking guidance points to a separate SQL evaluation repository; this README does not present its own accuracy numbers, so results on your schemas need independent evaluation.

HotRepo's take

The only dated signal is a single daily-board observation on 2026-10-27 at 240 stars, +75 that day. One board day cannot establish persistence or momentum, so interest here is unproven either way. Try it if you need a governed semantic layer for agent SQL and can operate the stack; first confirm whether the MCP and API paths can read the catalog without the web UI, since that determines whether this fits an existing agent harness.