Layer by Layer: Where Text-to-SQL Fails and the Semantic Model Wins

August 17, 2026 by Adam Kahn

I want to walk through why databases are good for transacting and storing data, but a semantic model paired with a knowledge graph is where analytical work lives. Bear with me, I am going down the tech rabbit hole.

There’s a pitch going around the industry right now that sounds great in a demo. Point an AI at your database, ask it anything in plain English, and let it write the SQL and return the data. For developers and technical staff, this may be helpful for ad hoc data requests or development, but for your business users doing analytics work, this is rife with problems. No semantic layer, no data model, analysis becomes very tricky.

Relationships
In a relational database, the connections between entities are implicit, and due to the highly normalized forms of the structure of databases, it means many hops across tables are needed to join effectively related elements. They’re locked inside foreign keys and only resolved at query time through joins. Stitching five tables together across different domains takes a developer, real time and a question someone already knew to ask. Ask a text-to-SQL model to do that cold, and it must reconstruct the join path from scratch on every single query hoping it picked the right one.

A semantic model works differently. Relationships aren’t buried. They’re defined up front and searchable in milliseconds. The AI doesn’t have to infer how occupancy connects to lease events and then connects to revenue. It follows links that are already encoded and can reason across several hops in a single pass. The semantic model allows you to literally pivot around a single fact across numerous grains to allow natural follow-on questions to drive deeper explorations around what and why. Slicing/filtering the lease-ups…should be defined.

At REBA, your data relationships live in the model itself, not in a developer’s head or foreign keys, so an agent never has to guess a join, nor invent a metric. Built from the finest grain of data, the semantic model can aggregate without a new calculation needing verification, the filters are prebuilt for meaningful analysis.

Meaning
Most benchmarks treat this as a translation problem, assuming the prompt contains every clue the model needs. Reality is messier. Ask an LLM for gross margin by region when the underlying column is named something like cst_gds_sld, and it reads the schema and guesses. It might interpret that metric differently than your CFO does. The query still runs, the numbers still look plausible, but more importantly it still fails an audit.

A semantic layer settles the meaning once. The agreed definition of a metric, which tables it pulls from, which filters apply, how returns and multi-touch attribution get handled, is encoded centrally, so every question resolves to the one number the business has already signed off on. Data governance matters in just this way!

At REBA, net operating income maps to a curated, finance-vetted calculation. That’s bulletproof metric retrieval, not fragile SQL generation. Further, change the lens on what you’re looking at, time, or level of aggregation and SQL just doesn’t perform, our model does.

Scale
Academic benchmarks tend to use schemas of 10 to 20 tables. Enterprise reality runs past 1,000 columns and 100 or more tables, which overwhelms even large context windows. The drop-off is steep. Once the schema outgrows the window, the model must guess which tables even matter, and a wrong guess at that stage is fatal.

A knowledge graph acts as the map and compass.  Given a question, it already knows which slice of data is relevant and why, because the table relationships are explicit and defined. The AI reasons over a curated subset instead of drowning in the full schema. In many ways, it acts as a progressive disclosure system, allowing meaning at each level from concept, to table, to measures and related attributes.

At REBA, the model scopes retrieval to what actually matters, so accuracy doesn’t erode as your portfolio’s data grows. Skills around common reports or metrics are token efficient, but the knowledge of the model makes those skills the starting point, changing aggregations or time does not break the query, it unlocks the information you need.

Structure
Our own experiments with a flatten a structured of our data model like RAG was far less effective than the use of a knowledge graph. At REBA, related concepts (leasing measures and marketing measures) stay connected, so context survives the trip from database to answer.

Trust
Agents have gotten better, but they cannot know any better than what they are given. Ad hoc queries that cannot be resolved the meaning of the measures to the framing of the prompt will just fail.

At REBA, every figure traces back to vetted logic, so your agent can find the meaningful measures, call the data, and your model guides the data towards your decision. You will be able to see the receipts and get an explanation all before you stand in front of the board room. The best analysts do this to earn trust in the numbers, so too can your Agent.  

Curious how a governed semantic foundation could change what your agents can safely see? Reach out to the REBA team to talk through it.