AI Tool Review · 2026

TextQL Review (2026): Features, Pricing & Verdict

TextQL is an agentic data analytics platform built around Ana — an AI data analyst designed not to bolt a chatbot onto a dashboard but to replicate the actual hierarchy of steps a human analyst works through. That framing is the product’s whole thesis, and it’s a sharper one than most “chat with your data” tools offer. Ask Ana a question in plain English (or in Slack, where much of the value lands) and it doesn’t just fire a text-to-SQL query into the void: it browses your existing BI tools and points you to a dashboard if the question’s already been answered, queries your semantic layer, reads your dbt documentation, references enterprise data catalogs like Alation and notes in Confluence or Google Drive, and asks for help when it doesn’t know — mimicking how a real analyst reasons across the whole stack rather than guessing from raw tables. Crucially, it does this without data migration or pipeline rebuilds: you connect Ana to your existing warehouse and SaaS tools and, TextQL claims, your data team runs real queries within about ten minutes. The platform is semantic-layer-native (dbt, Cube, LookML), BI-compatible (Tableau, Looker, Power BI), HIPAA and SOC 2 compliant, and deployable anywhere — public cloud, VPC or fully on-premises — with Ana running entirely inside your environment. Founded by CEO Ethan Ding, backed by ~$4.1M seed funding (Neo, DCM) with angels including dbt’s Tristan Handy, and already working with tens-of-thousands-employee organisations across media, life sciences, manufacturing and financial services (plus an NBA Launchpad slot), TextQL is a credible, technically ambitious entrant. Its pricing is genuinely modern and genuinely complex: consumption-based Agent Compute Units (ACUs) layered over seat tiers, which rewards careful modelling and punishes casual estimation.

7.5
Overall Score / 10
Agentic AI analyst (Ana) that reasons across your whole stack · semantic-layer-native · Slack-first · ACU consumption pricing
Best for
Mid-to-large data-mature orgs with a modern stack (dbt/Cube/LookML + Tableau/Looker/Power BI) wanting an AI analyst that reasons like a human across BI, catalogs and docs
Platform
Cloud, VPC or on-prem; Ana runs in your environment; connects warehouses + SaaS; Slack-first; no data migration or pipeline rebuilds
Key differentiator
Ana mimics a human analyst’s workflow — browses BI dashboards, queries semantic layer, reads dbt/Confluence/Alation docs — not just text-to-SQL
Pricing
Consumption-based Agent Compute Units (ACUs, 500/instance-hour) + seat tiers (Analyst 3 seats → Team → Enterprise); complex to estimate
Vendor
TextQL — founded by Ethan Ding; ~$4.1M seed (Neo, DCM); customers in media, bio, manufacturing, finance; NBA Launchpad participant

What Is TextQL?

Self-service analytics has a credibility problem, and TextQL’s founder names it directly: every conversation with data practitioners about self-service “starts with an eye roll,” because they’ve been sold fifteen years of disappointing products that are always ready tomorrow — after one more BI tool or a bit more data modelling. TextQL’s answer is to stop pretending an AI can answer data questions from raw tables alone, and instead build an agent that does what a good human analyst actually does: work across the entire data stack. Ana, TextQL’s AI analyst, is architected to mimic the hierarchy of responses a human analyst goes through. When you ask a question, it first checks whether the answer already exists — browsing your BI tools and pointing you to the right Tableau or Looker dashboard rather than rebuilding it. If it needs to compute, it queries your semantic layer (dbt, Cube, LookML) so it uses your governed business definitions rather than inventing its own, avoiding the “conflicting definitions” problem that plagues naïve NL-to-SQL. It grounds itself in your documentation — reading dbt docs, Confluence and Google Drive notes, and enterprise catalogs like Alation — and when it genuinely doesn’t know, it asks for help rather than hallucinating. The result is delivered where people already work, especially Slack, where a user can ask “what was our churn last quarter?” and get a written breakdown with segment splits and drivers inline. And it deploys without disruption: no data migration, no pipeline rebuilds, connect to your existing warehouse and query within roughly ten minutes. Within this site’s Data Analysis, BI & Spreadsheets category, TextQL occupies a distinctive niche — not the raw NL-to-SQL engine (that’s Seek AI’s lane) and not the enterprise planning suite (Pigment’s), but the agentic analyst that layers over and reasons across your existing modern data stack.

Core Features

Ana: the stack-aware agentic analyst

Ana is the product, and what distinguishes it is breadth of reasoning rather than a single trick. Where a basic text-to-SQL tool takes a question and emits a query, Ana runs a multi-step analytical workflow modelled on human analyst behaviour. It maintains a dynamic metadata engine that indexes documentation from Notion, Confluence, Google Drive and Microsoft Office, so it understands your business context, not just your schema. It’s BI-compatible with Tableau, Looker and Power BI — and critically, it browses those tools first, pointing users to an existing dashboard when a question has already been answered rather than wastefully recomputing. It carries an AI-boosted semantic layer for dbt, Cube and LookML, meaning it can both read and, when needed, write semantic-layer code, keeping answers consistent with governed definitions. Its underlying model is Python-proficient for genuine analytical work beyond SQL, and the whole thing is HIPAA and SOC 2 compliant — the reason it lands in regulated sectors like life sciences and finance. The Slack integration is more than a convenience: it’s the delivery surface that gets insights to non-technical business users without them ever opening a BI tool, and TextQL leans into it as the primary interface. Autonomous agents can also monitor, analyse and report on key metrics on a schedule (playbooks). The honest caveat: this breadth is powerful but assumes you actually have the modern stack it reasons over — a well-modelled semantic layer, documented dbt project, populated catalog. Organisations with messy, undocumented data get less of Ana’s differentiated value and more of a plain NL-to-SQL experience, so the payoff scales directly with your data maturity.

No-migration deployment and the modern-stack fit

TextQL’s deployment story is one of its strongest practical selling points, directly targeting the pain that makes analytics projects stall. There’s no data migration and no pipeline rebuild: you plug Ana into your existing warehouse and SaaS tools, and TextQL says your data team can run real queries within about ten minutes, with the rollout to business teams following once the technical setup lands. This “connect to your existing warehouse and get insights immediately” model contrasts sharply with platforms that demand months of onboarding, re-modelling or migration before delivering value — a genuine differentiator when new data solutions are expected to take a year to implement. Deployment flexibility matches enterprise requirements: Ana runs in public cloud, in your VPC, or fully on-premises, entirely within your environment with the same simple setup, giving complete control over data and infrastructure — essential for the regulated, security-conscious organisations TextQL targets. The compute model behind this is the Virtual Sandcastle Service: when you start a conversation with Ana or run a playbook, a dedicated sandbox is provisioned, stays warm for an hour after your last activity, and consumes compute during that window. The realistic caveat is that “10 minutes to first query” is the technical connection, not the full value — Ana’s differentiated stack-aware reasoning depends on it having indexed your docs, catalog and semantic layer, which is a richer setup than a bare connection. Treat the fast-start claim as true for basic querying and budget more time to unlock the agent’s full capability.

ACU consumption pricing and the tier structure

TextQL’s pricing is thoroughly modern and, in fairness, thoroughly complex — the aspect prospective buyers most need to understand before committing. Rather than flat per-seat SaaS, TextQL bills compute via purchasable Agent Compute Units (ACUs). Virtual compute instances consume 500 ACUs per instance-hour, and because a sandbox stays warm for an hour after last activity, a short burst of questions can hold a sandbox open (and consuming) for the full hour. On top of compute, AI inference is metered in ACUs per million tokens, with different models priced differently — cost-efficient models for simple queries, advanced reasoning models for complex analysis — and a Fast Mode option (for Opus-class models) that runs at 6× the standard ACU rate for speed. Caching, where available, cuts cost by reusing processed context across related queries. This consumption core sits under seat-based tiers: an Analyst tier (up to 3 seats, unlimited connectors, secrets manager, ontology builder, all integrations including Slack/dbt/Tableau/Teams), a Team tier (unlimited seats, role-based access control, SSO, priority 1-hour support), and an Enterprise tier (dedicated infrastructure, embed or white-label, on-prem/VPC deployment, dedicated account management). The upside is genuine pay-for-what-you-use fairness; the risk, which the vendor’s own docs make plain, is that consumption pricing is hard to forecast — a platform that looks affordable at low usage can escalate as adoption grows. Model your realistic query volume, account for the warm-sandbox hour and Fast Mode multiplier, and pressure-test costs at scale before signing.

Scored Categories

Agentic stack-aware reasoning (Ana)

8.8

Semantic-layer & BI integration

8.7

No-migration deployment & setup speed

8.5

Slack-first delivery to business users

8.4

Security & compliance (HIPAA, SOC 2, on-prem)

8.6

Pricing transparency & predictability

5.2

Fit for low-data-maturity orgs

5.0

Track record & maturity (seed-stage)

6.4

Pricing

Tier Structure Notes
Analyst Seats + ACU consumption Up to 3 seats, unlimited connectors, secrets manager, ontology builder, all integrations (Slack, dbt, Tableau, Teams)
Team Seats + ACU consumption Everything in Analyst plus unlimited seats, role-based access control, SSO, priority 1-hour support
Enterprise Custom Everything in Team plus dedicated infrastructure, embed/white-label, on-prem & VPC deployment, dedicated account management
Compute (ACUs) 500 ACUs / instance-hour Sandbox provisioned per workload; stays warm 1 hour after last activity, consuming ACUs continuously
AI inference ACUs per 1M tokens Varies by model; Fast Mode (Opus-class) at 6× standard rate; caching cuts cost by reusing context
TextQL’s ACU consumption model is fair in principle but genuinely hard to forecast — the single thing to model carefully before buying. Two mechanics drive surprise costs: the sandbox stays warm and billing for a full hour after your last activity (so sporadic questions throughout a day can keep it consuming), and Fast Mode runs at 6× the standard inference rate. Estimate realistic concurrent users and query frequency, factor the warm-hour behaviour and any Fast Mode use, and ask TextQL to model your specific scenario. The Analyst tier’s 3-seat cap makes it a sensible pilot to measure real ACU burn before scaling to Team. Confirm current ACU rates and tier features in TextQL’s docs, as consumption pricing details change.

Strengths

  • Ana reasons like a human analyst across your whole stack, not just text-to-SQL
  • Browses existing BI dashboards first — points to answers instead of recomputing
  • Semantic-layer-native (dbt, Cube, LookML) — uses governed business definitions
  • Grounds answers in dbt docs, Confluence, Google Drive and Alation catalogs
  • No data migration or pipeline rebuilds — query within ~10 minutes
  • Slack-first delivery gets insights to non-technical users where they work
  • HIPAA and SOC 2 compliant; deploy in cloud, VPC or on-premises
  • Autonomous agents/playbooks monitor and report on metrics on a schedule
  • Strong backing (dbt’s Tristan Handy) and real enterprise customers (media, bio, finance, NBA)

Weaknesses

  • ACU consumption pricing is complex and hard to forecast at scale
  • Warm-sandbox hour and 6× Fast Mode multiplier can inflate costs
  • Full value depends on a mature, well-documented modern data stack
  • Low-data-maturity orgs get a plainer NL-to-SQL experience
  • Seed-stage vendor (~$4.1M) — less battle-tested than incumbents
  • Analyst tier capped at 3 seats before stepping up to Team
  • “10 minutes to first query” understates full stack-aware setup time
  • Limited independent user reviews on major directories so far

Verdict: 7.5 / 10 — A Genuinely Different Agentic Analyst for Data-Mature Teams Willing to Model the Costs

TextQL scores 7.5 as one of the more architecturally thoughtful entrants in AI analytics — Ana’s design mimicking how a human analyst reasons across BI tools, semantic layers and documentation is a meaningfully better idea than bolting a chatbot onto raw tables, and the no-migration, Slack-first, on-prem-capable deployment fits the modern stack cleanly. For mid-to-large organisations with a well-modelled dbt/Cube/LookML semantic layer, documented data and a real self-service bottleneck, it’s a strong shortlist candidate that delivers value fast. The score is held back by two honest realities: the ACU consumption pricing is powerful but hard to forecast and can escalate with adoption, and the platform’s differentiated value scales with your data maturity — messy, undocumented stacks get a plainer experience. As a seed-stage vendor it’s also less battle-tested than incumbents. Pilot it on the Analyst tier, measure real ACU burn, and confirm your stack is documented enough to unlock Ana’s full reasoning before scaling.

Frequently Asked Questions

How is TextQL different from a plain “chat with your data” tool?

The difference is architectural and it’s the whole point of the product. A plain text-to-SQL tool takes your English question and generates a SQL query against your raw tables — fast to demo, but blind to context: it doesn’t know your governed metric definitions, doesn’t check whether an answer already exists, and can confidently produce a query that technically runs but means the wrong thing. TextQL’s Ana is built to mimic the hierarchy of steps a human analyst actually follows. It first browses your BI tools (Tableau, Looker, Power BI) to see if the question’s already answered by an existing dashboard and points you there. If it needs to compute, it queries your semantic layer (dbt, Cube, LookML) so it uses your governed business definitions rather than inventing its own — eliminating the conflicting-definitions problem. It grounds itself in your documentation (dbt docs, Confluence, Google Drive, Alation catalogs) to understand business context, and when it genuinely doesn’t know, it asks for help instead of hallucinating. That stack-aware reasoning is why TextQL positions itself as replicating a human analyst rather than adding a chatbot. The trade-off: this approach only shines if you have the modern stack it reasons over. On a mature, documented stack Ana is dramatically more capable than plain NL-to-SQL; on a bare warehouse with no semantic layer or docs, the gap narrows considerably.

How does TextQL’s ACU pricing work, and how do I avoid surprises?

TextQL bills consumption through Agent Compute Units (ACUs), and understanding two mechanics prevents most bill shock. First, compute: when you start a conversation with Ana or run a playbook, a dedicated sandbox is provisioned that consumes 500 ACUs per instance-hour — and critically, it stays warm and billing for a full hour after your last activity before auto-releasing. So a user asking a few questions across an afternoon can keep a sandbox consuming far longer than the active minutes suggest. Second, AI inference is metered separately in ACUs per million tokens, priced by model (cheap models for simple queries, expensive reasoning models for hard ones), with an optional Fast Mode for Opus-class models that runs at 6× the standard rate for speed. Caching, where available, reduces cost by reusing processed context across related queries. On top of this consumption core sit seat-based tiers (Analyst up to 3 seats, Team unlimited, Enterprise custom). To avoid surprises: estimate your realistic concurrent users and how often they’ll query, explicitly account for the warm-sandbox hour (not just active time), decide whether Fast Mode’s 6× premium is worth it for your use cases, and ask TextQL to model your specific scenario. Start on the 3-seat Analyst tier to measure actual ACU burn against real usage before committing to unlimited seats — piloting is the only reliable way to forecast a consumption model.

What kind of organisation is TextQL actually right for?

TextQL is best suited to mid-to-large, data-mature organisations that have already invested in a modern data stack and are hitting the self-service bottleneck it’s designed to break. The strongest-fit profile: you have a governed semantic layer (dbt, Cube or LookML), documented data (dbt docs, a populated catalog like Alation, notes in Confluence), established BI tools (Tableau, Looker, Power BI), and a business-user population that keeps queuing ad-hoc requests to an overstretched data team. For that org, Ana’s stack-aware reasoning delivers real, differentiated value, the Slack-first delivery reaches non-technical users, and no-migration deployment means fast time-to-value. Regulated sectors (life sciences, finance, healthcare) benefit specifically from HIPAA/SOC 2 compliance and on-prem/VPC deployment. The weaker fits: small teams or organisations with immature, undocumented data get less of Ana’s differentiated reasoning (falling back toward plain NL-to-SQL) while still facing consumption-pricing complexity, and cost-sensitive buyers wanting predictable flat pricing may find ACUs hard to budget. As a seed-stage vendor, TextQL also suits teams comfortable adopting a newer, less battle-tested platform in exchange for a genuinely differentiated approach. The honest test: if your semantic layer and documentation are solid, TextQL is exciting; if they’re not, fix that first or choose a simpler tool.