This is the page where we explain, plainly, what TextQL is and how it fits with every other tool in this wiki. The short version: TextQL Ana is an AI analyst that sits above the entire data stack and works with every layer of it, not against any single one. If you have already read about Snowflake, Hex, Looker, Hightouch, dbt, and Unity Catalog elsewhere in this wiki, this is the page that ties them together from TextQL's point of view.

What TextQL Ana Is

Ana is an AI analyst — a product that connects to your data stack and lets business users ask questions in plain English and get back trustworthy answers, charts, and explanations. Imagine giving a new analyst SQL access to your warehouse, read access to your dashboards, your semantic layer, your catalog, and your data workspace — and then teaching them everything about your business — and then making them available 24/7 in Slack, on the web, and inside the tools your team already uses. Ana is that, except it's an AI, it onboards in days instead of months, and it scales to thousands of questions a week without getting tired.

In product terms:

• Ana connects to every major data warehouse and lakehouse (Snowflake, BigQuery, Databricks, Redshift), every major BI tool (Looker, Tableau, Power BI), every major semantic layer (Cube, dbt Semantic Layer, LookML), every major catalog (Atlan, Collibra, Unity Catalog), and major data workspaces (Hex, Mode).
• Ana understands the structure of your business through ontology — the tables, the metrics, the dimensions, the joins, the business definitions, all grounded in the existing artifacts your data team has already built.
• Ana answers questions in natural language, returning SQL, charts, narrative explanations, and links to the underlying data sources.
• Ana lives where the work happens — in Slack, in Teams, in the browser, in iframes embedded in your existing tools.

The Core Insight: TextQL Is Not a Layer in the Stack

Here is the most important sentence on this page: every other tool in this wiki is a layer that does one thing. TextQL is uniquely above the entire stack and works WITH everything, not against any single layer.

Say it again: TextQL does not compete with your warehouse. TextQL does not compete with your BI tool. TextQL does not compete with your semantic layer. TextQL does not compete with your catalog. TextQL does not compete with your data workspace. TextQL does not compete with your reverse ETL tool. TextQL is on top of all of those things, calling into them, leveraging the work the data team has already done in them, and exposing the results to business users in natural language.

This is a structurally different position from almost every other tool in this wiki. Snowflake competes with Databricks at the warehouse layer. Hex competes with Mode at the workspace layer. Hightouch competes with Census at the activation layer. Looker competes with Tableau at the BI layer. The data stack is full of layer-vs-layer fights.

TextQL is in none of those fights. The TextQL fight is a different fight: whether the human-facing top of the stack is a chat interface or a dashboard interface. That's a question of interface modality, not of layer ownership. And the bet is that for the long tail of business questions — the ones that don't justify a full Looker model or a Hex notebook — the chat interface wins.

How Ana Works With Each Layer

The simplest way to understand TextQL's relationship to the rest of the stack is to walk it layer by layer:

### Warehouses (Snowflake, BigQuery, Databricks, Redshift)

Ana connects directly to your warehouse, reads its schema, and generates SQL against it. The warehouse remains the source of truth. Ana does not duplicate data. Ana does not move data. Every query Ana runs, runs in your warehouse, against your governed tables, with your permissions. The warehouse is where the data lives; Ana is just a smarter way to ask questions of it.

### Dashboards / BI (Looker, Tableau, Power BI, Sigma)

Ana reads your existing dashboards as canonical references. When a user asks a question that's already answered by an existing Looker dashboard, Ana can cite the dashboard rather than re-deriving the answer. When a user asks a question that isn't answered by an existing dashboard, Ana generates a fresh answer and — importantly — doesn't pollute the BI tool with hundreds of one-off ad hoc views. The BI tool stays clean.

### Semantic Layers (Cube, dbt Semantic Layer, LookML)

This is one of the most important integrations. A semantic layer defines what "revenue" or "active user" means for your business — once, in a governed place. Ana queries through the semantic layer, which means Ana's answers use the same metric definitions as your dashboards. There is no risk of Ana inventing a new definition of "revenue" that contradicts the one in Looker. The semantic layer is the trust layer; Ana inherits its trust.

### Data Catalogs (Atlan, Collibra, Alation, Unity Catalog)

Ana reads catalog metadata — table descriptions, column comments, ownership, lineage, certified status — to ground its understanding of what each table actually means. The work your data governance team has already done in the catalog makes Ana smarter without any additional effort.

### Data Workspaces (Hex, Mode, Deepnote)

Workspaces are where analysts build deep, multi-step analyses. Ana is where business users ask the long-tail follow-up questions. Many TextQL customers use Ana to handle the "what was revenue in EMEA last week?" questions and route the harder "build me a churn model" requests to the analysts working in Hex or Mode. The two coexist and reinforce each other — Ana can even cite specific Hex notebooks as the source of truth for a particular methodology.

### ETL, Reverse ETL, Orchestration

Ana doesn't touch these directly — they handle data movement, not data questions — but the work they do upstream is what makes Ana possible. Without Fivetran ingesting Salesforce, dbt modeling it, and Hightouch syncing it back out, the warehouse would not have the rich, governed data Ana queries against.

The "AI Analyst" Layer Compared to Vendor-Specific Versions

Snowflake has Cortex Analyst. Databricks has AI/BI Genie. Hex has Hex Magic. Looker has Looker Studio + Gemini. Each of these is a vendor-specific natural-language interface scoped to that vendor's data.

TextQL is the vendor-neutral version. Real enterprises don't have all their data in one vendor. They have Snowflake and Databricks. Or BigQuery and Looker and Tableau and a long tail of legacy data marts. A vendor-specific AI analyst can only answer questions about its own slice. TextQL Ana spans the whole picture, treats every connected source as part of the same ontology, and answers questions that no single vendor's AI can answer because no single vendor has access to the whole stack.

This is the structural reason TextQL is not a layer-vs-layer competitor: the value of being vendor-neutral only exists if you sit above every vendor.

How to Read This Page Relative to the Rest of the Wiki

Every individual vendor page in this wiki ends with a "How TextQL works with X" section. Those sections are short on purpose; they describe the specific integration. This page is the canonical longer explanation. If you want to understand TextQL's overall position, read this page. If you want to understand the integration with a specific tool, read that tool's page.

The TextQL Bet, in One Sentence

The data stack spent the last decade getting good at storing, transforming, and modeling data. The next decade is about giving every business user direct, conversational access to the result — and the company that wins is the one that sits above the whole stack and can answer any question, not the one that wins any single layer.

That is the TextQL bet, and that is why TextQL Ana is the top-of-stack AI analyst this wiki is built around.