Pretensor vs data catalogs

Pretensor is in beta — 0.1.0 is the first stable release. The CLI interface is stable; the MCP tool signatures may still evolve between minor versions until 1.0.0. Pin your version.

The question comes up often: “We already have a data catalog — do we need Pretensor?” The honest answer is that they solve different problems for different audiences. This page works through where they diverge and where they can coexist.

What data catalogs are built for

Data catalogs exist to help human analysts find and understand data assets. A typical catalog indexes table names, column descriptions, owner tags, and certified-asset status. It surfaces that information through a web UI where an analyst can search, browse, and filter before writing a query.

The underlying model is: a person opens a browser, types a search term, reads prose descriptions, decides which table to use, and then goes to their SQL editor. The catalog’s job is to shorten step two — the browsing and discovery phase.

Everything downstream of that model — the rich search UI, the business glossary, the certification workflows, the lineage diagrams rendered in a web canvas — is tuned for human cognition. You scan, you read, you click.

That is genuinely useful. If your team has 300 tables and five analysts who need to find the canonical orders table without asking Slack, a catalog helps.

What AI agents actually need

An agent writing SQL against your database does not browse a web UI. It issues a tool call, receives a structured response, and generates SQL from that context. The requirements are different at every level:

• Machine-readable, not prose-readable. A column description of “the total after discounts are applied” is good for a human, mediocre for an agent that needs to know the type, nullability, and which discount_id foreign key connects it.
• FK-backed join paths, not ER diagrams. An agent needs to know that orders.customer_id points to customers.id as a confirmed FK — not a diagram image. It needs that edge in a traversable form so it can plan a three-table join without hallucinating an intermediate table.
• Deterministic answers in one tool call. An agent that has to call list_tables, then describe_table on each candidate, then infer joins from column names is burning tokens and accumulating uncertainty. A precomputed graph answers “what’s the join path from orders to invoices?” in a single traverse call.
• Schema-only by design. Agents don’t need row data to plan queries. They need structure. Pulling zero rows per tool call is not a coincidence — it’s the privacy model.

A standard data catalog was not designed around any of these requirements because, when most catalogs were built, agents weren’t the consumer.

Output surface: UI vs MCP

The clearest functional difference is where the output goes.

A catalog ships an HTML interface. Humans hit it. Programmatic access — if it exists — is typically a REST API added later, with uneven coverage of the catalog’s features.

Pretensor ships an MCP server. See getting started for the one-command setup (pretensor init). There is no UI. The 12 read-only MCP tools are the product. An agent host — Claude Code, Cursor, Cline, Goose, or any MCP-compatible client — attaches to the server and calls traverse, impact, compile_metric, or query directly. The response is structured JSON the agent can reason over without parsing prose.

This is not a missing feature in Pretensor. It is the design. Building a catalog-style UI on top of an agent-native graph would be plumbing in the wrong direction.

Authoring model: manual vs auto-generated

Most catalogs require humans to author or curate the content that makes them useful. Column descriptions, domain tags, certified-asset status, glossary terms — someone has to write those. The catalog is only as good as the curation effort behind it.

Pretensor introspects. You point it at a connection string and run pretensor index. It reads the schema, builds the knowledge graph, and computes FK-backed join paths from the foreign key constraints in your database. No manual authoring required to get the structural layer.

The trade-off is real: Pretensor has no place for a human-authored business glossary. “Revenue” might mean three different things in your organization, and Pretensor cannot resolve that ambiguity — it can only tell the agent what columns exist and how they relate structurally.

If that semantic layer matters (and often it does), the catalog provides it. Pretensor does not try to.

What Pretensor doesn’t do

This matters, so it gets its own section.

Pretensor has no web UI. There is no place for an analyst to browse certified assets, add column descriptions, or mark a table as deprecated. If your team’s workflow depends on any of that — and many teams’ workflows do — Pretensor does not replace it.

There is no business-glossary curation. No certified-asset workflow. No lineage diagram rendered in a canvas. No integration with Tableau or Looker as BI consumers. No Airflow or orchestrator metadata extraction.

Pretensor reads your schema structure: tables, columns, foreign keys, view definitions, grants. It builds a graph from that. It serves the graph over MCP. That is the full scope. See the schema graph architecture for what the graph contains.

The beta status adds more caveats. Python 3.13 is untested; use 3.11 or 3.12. Scheduled reindex is not in the OSS release — run pretensor reindex manually. BigQuery support is available but lags behind Postgres in coverage. Automatic multi-database entity resolution is part of the hosted offering, not the OSS release.

If you need an enterprise-grade cataloging platform with governance workflows, Pretensor is the wrong tool.

When to use both

The catalog and Pretensor serve different audiences from the same database. That makes them composable, not adversarial.

Consider a company with a 150-table Postgres instance:

Need	Tool
Analyst browsing tables before writing a query	Data catalog
Column descriptions curated by domain owners	Data catalog
Certified-asset governance workflow	Data catalog
AI agent generating SQL in Claude Code	Pretensor
Agent computing join path across four tables	Pretensor
Agent checking blast radius before a schema change	Pretensor

The catalog is the human interface to your data. Pretensor is the agent interface. Running both means your analysts have a place to curate and discover, and your agents have a graph they can traverse without replicating that curation work in prompts.

The setup is additive: index Pretensor against the same connection string the catalog reads. The catalog’s curated descriptions do not flow into Pretensor today — that is a gap worth noting. Structural knowledge (tables, columns, FKs, join paths) is what Pretensor contributes to the agent layer.

“Pasting schema in the prompt works up to ~30 tables. Breaks at 200. We precompute once, serve forever.” If your database is in that range and your agents are writing SQL against it, a catalog’s REST API is not the right retrieval surface — a graph served over MCP is.