--- title: How dhino compares - text-to-SQL, semantic layers, Microsoft Fabric description: dhino sits in a different layer than most tools it gets compared to. See how it differs from text-to-SQL and semantic layers, and where it fits alongside Microsoft Fabric. url: https://dhino.io/compare/ --- # How dhino compares dhino is a governed access layer, not a data platform or a query generator. Here is how it differs from the tools it gets compared to, and where it fits alongside Microsoft Fabric. ## The short answer Every request to dhino runs a pre-defined template with deterministic execution. The same question returns the same answer, for every consumer, with field-level access and audit trails built in. That is the core difference. ## dhino vs text-to-SQL Text-to-SQL generates a query at runtime and hopes it is right. dhino runs pre-defined templates. That distinction decides everything else. Text-to-SQL dhino Generates a SQL query at runtime from natural language Executes a pre-defined template with parameterized logic Accuracy degrades on complex schemas; results can vary each time Same question, same answer, every time. Deterministic. Governance is applied at the query level, often as a prompt Field-level access, role-based permissions, and audit trails built in Primarily a tool for developers and analysts One layer for business users, applications, and AI agents Good for ad-hoc exploration Built for production data access [What is text-to-SQL?](https://dhino.io/glossary/text-to-sql) [Read the full comparison](https://dhino.io/blog/template-based-vs-text-to-sql) ## dhino vs a semantic layer A semantic layer describes how to query the data. dhino executes against the data. They overlap on modeling; they diverge on execution. Semantic layer dhino Describes the data: entities, metrics, joins Executes against the data through parameterized templates Still relies on generated queries underneath No runtime generation. Templates are tested and fixed. Better UX than raw SQL, same execution risk No execution risk. Same template, same result. Typically consumed by BI tools Consumed by humans, applications, and AI agents through one layer [What is a semantic data layer?](https://dhino.io/glossary/semantic-data-layer) ## dhino and Microsoft Fabric Fabric is a data platform: lakehouse, compute, BI. It is Microsoft's answer to Databricks and Snowflake. dhino is a governed access layer that sits on top of whatever data you have, Fabric included. Fabric is where data lives. dhino is how it gets served to the people, applications, and AI agents that need it. A Fabric customer is typically a strong fit for dhino: Fabric gives them the data, dhino gives every consumer a governed path to it. The categories dhino actually displaces: text-to-SQL tools, hand-rolled semantic layers, and the "every team builds its own governed API" pattern. ## Going deeper If you are evaluating MCP servers for Dataverse, the differences between Microsoft's standard implementation and a governed alternative shape what AI agents can do safely. [Dataverse MCP server: dhino vs Microsoft](https://dhino.io/compare/dataverse-mcp) ## Frequently asked questions Is dhino a competitor to Microsoft Fabric? No. Fabric is a data platform: lakehouse, compute, BI. dhino is a governed access layer above whatever data you have. A Fabric customer is typically a strong fit for dhino, because Fabric gives them the data and dhino gives every consumer a governed path to it. When is text-to-SQL the right choice? For ad-hoc data exploration by SQL-literate analysts, where an occasional wrong answer is acceptable. Text-to-SQL is fast for one-off questions in known schemas. For production data access, recurring questions, or any consumer who cannot read SQL to verify the answer, deterministic templates are safer. Does dhino replace a semantic layer? It overlaps on modeling and diverges on execution. A semantic layer describes how to query data; dhino executes pre-defined templates against it. If you already run a semantic layer for BI, dhino sits beside it to serve governed data to humans, apps, and AI agents. If you do not have one yet, dhino replaces the "every team builds its own data API" pattern without adding a separate semantic layer. How is dhino different from a stored procedure or a hand-rolled API? The mechanism is similar: a pre-defined operation that parameters can be passed to. The difference is scope. A stored procedure lives in one database and serves one application. dhino templates serve every consumer (Fetch, Trust, Integrate, Publish) through one governed layer, with field-level access, role-based permissions, audit trails, and observability built in. Most teams end up rebuilding all of that for every new API; dhino does it once. Why does runtime generation versus pre-defined templates matter? Generated queries can drift. The same question on Monday and Friday may produce different SQL because the model interpreted the prompt differently. Pre-defined templates are tested, fixed, and parameterized. Same inputs return the same outputs every time. For business-critical data, that determinism is the difference between trustworthy answers and confident guesses. ## Talk to us about where dhino fits Every data environment is different. Tell us what you are running and we will tell you honestly where dhino fits and where it does not.