Natural language → SQL (self-serve analytics)

What automation does

Natural language → SQL — an AI agent that translates natural language questions into SQL queries against a data warehouse. Instead of filing a ticket to the analytics team and waiting two days, an employee gets an answer in seconds.

Core tasks

1. Translates the question into SQL. "How many customers from Germany made more than three purchases in the last quarter?" becomes a valid SQL query with JOINs and aggregations.
2. Executes the query in the warehouse. The agent connects to Snowflake, BigQuery, or Redshift via a service account and reads only permitted schemas.
3. Returns the result in a convenient format. A table, chart, or Slack message with an explanation of exactly what was calculated.
4. Remembers the team's context. A business glossary ("active customer", "net revenue", "launch cohort") is stored in the semantic layer and applied across all queries.
5. Explains the SQL before execution. The user sees the generated query and can adjust it if something has been misunderstood.

What it does NOT do

• Does not invent new metrics if the business glossary is not defined.
• Does not fix poor data quality: if there is garbage in the warehouse, the agent will return the same garbage faster.
• Does not replace an analyst for tasks requiring a multi-step hypothesis or complex statistical processing.
• Does not write queries blindly without access to the schema — without onboarding, accuracy drops below an acceptable level.
• Does not make decisions: it outputs data, not recommendations for action.

Typical configuration options

Solo / team of 1-5 people. One source is connected (PostgreSQL or Google BigQuery), a dictionary of 10-20 metrics, interface via a Slack bot or web chat. The main use case — the founder asks sales and cohort analytics questions directly, without pulling in the only analyst. Setup takes 3-5 working days. One setup specialist and data access are sufficient. The effect is immediate: 3-5 hours per week that previously went to manual exports are returned to productive work.

SMB / team of 6-30 people. Two to three sources: CRM (HubSpot or Salesforce), product analytics (Amplitude or PostHog), finance. A semantic layer with 50-100 metrics, row-level security by role (sales sees their pipeline, marketing — campaigns, finance — revenue). Integration with BI (Metabase, Looker) or a standalone UI. Setup — 1-2 weeks, including team training. Saves 20+ hours/month for the data team and handles the majority of ad-hoc requests.

Enterprise / 30+ people. A central warehouse (Snowflake, BigQuery), integration with corporate identity (SSO, SAML), a full audit log of every query, an approval workflow for queries to sensitive fields. The metrics dictionary is part of the data catalog (Alation, Collibra). Setup — 4-8 weeks: a pilot on one department, then rollout. Requires a dedicated data engineer, a security review, and a stakeholder engagement plan.

Who this is for

• Founders and managers whose data questions arise faster than analysts can answer them.
• Teams where data knowledge lives in the heads of two or three people and breaks down when they go on leave.
• Sales and support managers who need a data export here and now for a client conversation.
• Product teams testing hypotheses: a quick answer to "what if" matters more than the perfect query.

How it works

Automation is built in three layers: data connection, semantic layer, and query interface. An AI agent based on a language model or Snowflake Cortex processes the question, relying on schema metadata and a glossary.

Technology stack

1. Data warehouse connection. Service account with read-only access to selected schemas. Snowflake, BigQuery, Redshift, Postgres, ClickHouse are supported.
2. Schema indexing. The agent reads DDL, table and column comments, foreign keys. This is turned into a vector index that is available with every query.
3. Semantic layer. YAML or UI where you define metrics: "MRR = sum of active_subscriptions.monthly_price", "active customer = purchased within the last 30 days". Eliminates ambiguity.
4. LLM engine.AI model for complex queries, Snowflake Cortex for workloads within Snowflake. The choice depends on compliance and budget.
5. Query execution. SQL is executed in the warehouse, the result is formatted as a table, chart, or text explanation.
6. Interface. Slack bot, web chat, plugin for Metabase/Looker, or internal UI.

Step-by-step scenario

1. An employee types a question in Slack: "What is the trial conversion rate for the /ai-audit landing page over the last month?"
2. The agent selects relevant tables (pageviews, signups) and finds the conversion definition in the glossary.
3. Generates SQL, shows it to the user along with an explanation: "Calculating the ratio of trial sign-ups to unique visitors of the /ai-audit page over 30 days".
4. After confirmation, executes the query, returns the result and a link to the chart.
5. Logs the question, SQL, and result in the audit trail.

Alternative approaches

Natural language → SQL is not the only way to get answers from data. Below is a qualitative comparison of three approaches.

No-code BI remains a strong option for standard reports that everyone looks at every day. AI automation wins where there are many questions, they are non-standard, and they are asked by people without SQL skills. A manual request to an analyst is needed for tasks with a high cost of error: financial reporting, regulatory queries, deep-dive research.

In practice, the three approaches coexist. A typical split: BI covers the bulk of standard queries, the AI agent handles ad-hoc load, analysts focus on complex and critical tasks.

Security and compliance

Data access is a sensitive area. Grow2.ai configures several layers of protection by default: service account with read rights only on explicitly listed schemas, row-level security by role (sales does not see HR data), audit log of every query with user_id, timestamp, and SQL text. For enterprise, an approval workflow is added for queries to sensitive columns and SSO via a corporate identity provider.

For GDPR and SOC 2 compliance, it is important that the LLM provider does not use your queries for training. Snowflake Cortex and LLM via AWS Bedrock provide such guarantees on enterprise tiers. If data cannot be sent to the cloud, a self-hosted option is possible, but accuracy on complex queries decreases.

What you need before launch

Automation works better the cleaner the data and the clearer the business logic. Without preparation, the agent will generate formally valid but meaningless queries.

Prerequisites

1. A single data warehouse or data lake. If data is scattered across CRM, Google Sheets tables, and CSV files, an ELT process (Fivetran, Airbyte, dbt) is needed first.
2. Schema with comments. Every key table and column must have a clear description. Without this, the agent guesses the meaning and makes mistakes.
3. Business glossary. A document with definitions of key metrics: MRR, churn, active customer, cohort. 20-50 metrics for SMB, 100+ for enterprise.
4. Access and identity. A service account for the agent, roles for users, row-level security where needed.
5. Pilot question set. 30-50 typical questions from future users. Accuracy is tested against them before rollout to the entire team.

Team

• Data engineer or analyst — sets up the semantic layer and glossary. 10-20 hours in the first week, then on-demand support.
• Product or department owner — formulates pilot questions, validates answers, collects team feedback.
• Security / compliance — if the industry is regulated (finance, healthcare), joins the access review.

Potential pitfalls

• Launching without a semantic layer. Teams try to save a week and connect the warehouse directly. Accuracy drops to 40-50%, trust in the system collapses, the project gets shut down. The glossary is not an option — it is the foundation.
• Ignoring data quality. The agent will respond quickly, but if the table has duplicates and gaps, the answer will be wrong. Data quality first, then AI on top.
• Overly broad access. Users see what they shouldn't: financial figures, customer personal data. Row-level security must be configured before the first query, not after an incident.
• Lack of human review on critical questions. Quarterly revenue for the board of directors or data for an investor should not be taken from an AI chat without review. Define a list of 'red zones' where the agent assists but does not finalize.
• No success metrics. Without measuring accuracy and time savings, the project cannot be justified or improved. From day one, log questions, answers, time, and user ratings.