# Generative AI for databases: text-to-SQL, vector search and safe use > Generative AI for databases turns plain-language questions into SQL and searches data by meaning. How it works, how accurate it is and how to use it safely. - URL: https://computese.com/generative-ai-for-databases/ - Author: Duong Quan Nguyen, CEO, Computese - Published: 2024-07-26 - Updated: 2026-09-25 - Topics: Data, AI & automation ## In short - Generative AI works with databases in three practical ways: it turns plain-language questions into SQL (text-to-SQL), finds records by meaning with vector search such as pgvector, and helps engineers write, tune and document queries. - Accuracy depends on the context around the model. The Spider 2.0 paper's agent solved 21.3% of enterprise tasks; as of September 2026 the best BIRD test score is 82.39%, against a human score of 92.96%. - The costly failure is SQL that runs and looks right but answers a different question. Metrics defined in a semantic layer, verified queries, visible SQL and a person who checks the number before a decision are the controls that work. - Let the database enforce the rules: run generated queries read-only as the person asking, with row-level security, cost limits and timeouts, and treat text stored in your data as possible prompt injection. Generative AI for databases means using large language models on stored data in three ways: turning a plain-language question into SQL (text-to-SQL), finding records by meaning with vector search, and helping engineers write, tune and document queries. It can be trusted only when a semantic layer defines your metrics, the database enforces permissions and a person checks answers before decisions. This guide explains how text-to-SQL works, what the Spider 2.0 and BIRD benchmarks say about its accuracy on real schemas, which database and warehouse products offer natural-language queries as of September 2026, how vector search with pgvector brings retrieval into PostgreSQL, and the control for each risk, from SQL that is wrong but looks right to prompt injection hidden in your own data. ## What generative AI does with a database Four different jobs travel under the same label. They use different techniques and fail in different ways, so separate them before choosing a tool. | Job | What the model does | Where you find it | What goes wrong | | ---------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Answer questions in plain language | Writes SQL (or DAX, or KQL) from a question, runs it and explains the result | Snowflake, Databricks, BigQuery, Microsoft Fabric, Redshift, Oracle | A query that runs and answers a slightly different question | | Search by meaning | Turns text into embeddings and finds the nearest records, often to ground an assistant's answer | pgvector for PostgreSQL, SQL Server 2025, BigQuery | The right passage is missed, or one the user should not see is retrieved | | Help with database work | Drafts, explains and tunes queries, proposes schemas, writes documentation | Gemini in BigQuery, Copilot in Azure SQL Database, Databricks | Confident advice that is wrong for your data or workload | | Model the data itself | Learns a probabilistic model of a table to predict values, find anomalies or generate synthetic rows | Research systems such as MIT's GenSQL | Mostly research; the answers are only as good as the model's fit | The last row is what MIT meant when it [announced GenSQL on July 8, 2024](https://news.mit.edu/2024/mit-researchers-introduce-generative-ai-databases-0708) as a generative AI system for databases. GenSQL, presented at PLDI 2024, adds a few primitives to SQL so a query can ask a probabilistic model of a table for predictions, anomalies, missing values or synthetic data, each answer with a calibrated measure of uncertainty. [Its paper](https://arxiv.org/abs/2406.15652) reports a 1.7 to 6.8 times speedup over the closest competitor on its benchmark set. It remains a research system rather than a warehouse feature, so the rest of this guide covers the first three jobs, the ones most teams meet first. ## How text-to-SQL works Text-to-SQL, also called NL2SQL, converts a question such as "What was revenue by region last quarter?" into a query, runs it and returns the result. A language model does the translation, but most of the work in a good system happens around the model. [A survey of the field](https://arxiv.org/abs/2408.05109) (revised in August 2026) describes modern systems in three stages, pre-processing, translation and post-processing, built from modules such as schema linking and execution-guided correction. In practice the loop looks like this: 1. **Find the relevant schema.** Schema linking picks the tables and columns the question needs from metadata: names, descriptions, keys and sometimes sample values. A warehouse with thousands of columns does not fit in a prompt, so this step decides what the model can see at all. 2. **Add business meaning.** Metric definitions, synonyms, join paths and verified example queries tell the model that "revenue" means net of refunds and "last quarter" means your fiscal quarter. [Snowflake's documentation](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst) makes the point directly: models given only a schema struggle, because a schema lacks business definitions and metric rules. 3. **Generate the query** in the right dialect. BigQuery, Snowflake, T-SQL and PostgreSQL differ in date functions, quoting and row limits. 4. **Check it before and after it runs.** Parse it, reject anything but a single read-only statement, estimate its cost, then run it. If the database returns an error, feed the error back and let the model correct the query. 5. **Run it as the person who asked,** with their permissions, never with an administrator's. 6. **Return the result with its working:** the SQL, the definitions it used and a short plain-language summary, so someone can tell whether the question was understood. ![A laptop sends a question to a gear that reads a table outline and a card of metric definitions, both framed in orange, then passes a query sheet through a check mark into a database that returns a small table.](https://computese.com/images/blog/generative-ai-for-databases/pipeline.28deb1db43-1536.webp) *Given only a schema, the model has to guess what revenue means; the metric definitions beside it remove the guess.* The hardest part is rarely SQL syntax. It is working out what the question means. The survey's example is a date: "Labor Day in 2023" is September 4 in the United States and May 1 in China. Inside a company, "active customer", "churn" and "last quarter" carry the same ambiguity, and only your own definitions resolve it. ## How accurate is text-to-SQL on real databases? Three public benchmarks show how far text-to-SQL has come. They score results, not SQL text: an answer counts when it matches the result of a reference query written by people (execution accuracy, or a success rate for Spider 2.0's multi-step tasks). | Benchmark | What it tests | What the results show | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Spider 1.0 (2018) | Cross-domain questions over databases with few rows of content | Largely solved: GPT-4-based methods reached 91.2% execution accuracy, as the Spider 2.0 paper notes | | [BIRD](https://arxiv.org/abs/2305.03111) (NeurIPS 2023) | 12,751 questions over 95 databases (33.4 GB, 37 domains), with dirty values and business knowledge | ChatGPT scored 40.08% at publication, against a human score of 92.96%; the [best test score](https://bird-bench.github.io/) as of September 2026 is 82.39% | | [Spider 2.0](https://arxiv.org/abs/2411.07763) (ICLR 2025) | 632 workflow tasks from enterprise use cases, on databases that often exceed 1,000 columns, in systems such as BigQuery and Snowflake | The paper's o1-preview agent solved 21.3%; as of September 2026, [leaderboard](https://spider2-sql.github.io/) entries reach 96.70% on Spider 2.0-Snow and 76.23% on Spider 2.0-Lite | What these numbers mean for your own data: - **The system around the model matters as much as the model.** On Spider 2.0-Snow, moving the benchmark's reference agent from Claude 3.5 Sonnet to Claude 4 Sonnet raised its score from 15.54% to 25.78%. Putting the same Claude 4 Sonnet inside another team's agent raised it to 61.43%. - **Business knowledge is part of the input.** BIRD pairs its questions with evidence hints, such as the fact that a loan condition means an account type of OWNER, and the leaderboard's top entries use those hints. In production, that hint is your semantic layer. Without one, do not expect benchmark numbers. How to build one as part of an analytics stack is covered in [building data analytics software](https://computese.com/building-data-analytics-software/). - **Even the best systems miss more than one question in six.** A top BIRD test score of 82.39% leaves 17.61% of answers wrong, on questions that come with hints. - **A matching result is not proof of the right meaning.** Execution accuracy compares result sets, and the survey notes that queries for different questions can return identical results, so a wrong query can be scored as right. - **Your schema is not a benchmark.** The only accuracy figure that counts is the one you measure on your own questions, with answers someone has checked. ## Natural-language queries in database and warehouse products Each of the platforms below offers a way to ask questions in plain language. The details below come from each vendor's documentation as read in September 2026. Names and limits change often, so check the current page before you plan around them. | Product | What it does | What grounds the SQL | Guardrails in the documentation | | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | [Snowflake Cortex Analyst](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst) | A REST API that answers questions over Snowflake data; Snowflake now recommends moving to Cortex Agents, which include its capabilities | Semantic views with metrics, dimensions and join relationships, plus a [verified query repository](https://docs.snowflake.com/en/user-guide/views-semantic/verified-query-repository) | Follows role-based access control; billed per message, with the warehouse time to run the SQL on top | | [Databricks Genie Agents](https://docs.databricks.com/aws/en/genie-agents/concepts) (formerly Genie spaces) | A chat that returns SQL, a results table and charts | Unity Catalog metadata, an author-curated knowledge store, example SQL and trusted assets | Generated queries are always read-only; data access is checked as the end user, with row filters and column masks | | Google BigQuery | [Conversational analytics](https://cloud.google.com/bigquery/docs/conversational-analytics) with data agents, and [Gemini SQL generation](https://cloud.google.com/bigquery/docs/write-sql-gemini) in the query editor | Agent instructions, glossary terms and verified queries (previously called golden queries) | Google warns output can seem plausible yet be incorrect, and asks you to validate it | | [Microsoft Fabric data agent](https://learn.microsoft.com/en-us/fabric/data-science/concept-data-agent) | Generally available; answers across lakehouses, warehouses, Power BI semantic models and KQL databases (NL2SQL, NL2DAX, NL2KQL) | Instructions and up to 100 example queries per data source, with up to five sources | Only read queries, run with the user's own credentials; row-level and column-level security apply to semantic models | | [Amazon Redshift query editor v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-generative-ai.html) | Amazon Q generative SQL writes SQL in notebooks from your prompt and schema | The connected database's schema, and optionally your account's query history | Review before running; SQL that would change the database might only produce a warning | | Oracle Autonomous AI Database | [Select AI](https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/select-ai-keyword-prompts.html): `SELECT AI` with actions such as `showsql`, `runsql` and `narrate` | An [AI profile](https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/select-ai-manage-profiles.html) that lists the tables and views to use, with their names, columns and comments | `runsql` is the default action; `narrate` sends query results to the model unless an administrator disables it | The pattern across vendors matches the lesson of the benchmarks: curated definitions, verified examples, the user's own permissions and SQL you can see. Analysis beyond single queries follows the same rules. BigQuery's conversational analytics can call functions such as `AI.FORECAST` and `AI.DETECT_ANOMALIES`, Genie's agent mode runs several queries and returns a report with citations, and Gemini in BigQuery writes Python in notebooks from a plain-language request. Those answers need the same checking as a single query, and more of it. On PostgreSQL or MySQL you run yourself, you usually assemble the same loop from a model API and the controls in the rest of this guide. ## Vector search inside your database Text-to-SQL answers questions about numbers. Many questions are about text instead: what a contract says about renewal, or which support tickets describe the same fault. For those, an embedding model turns each passage into a vector, a list of numbers that places similar meanings close together, and a nearest-neighbour search finds the passages closest to the question. Retrieval-augmented generation (RAG) then hands those passages to a language model to answer from. ![Document pages are cut into cards that become dots inside a database. The question, made into an orange dot the same way, sits among them, and a dashed circle gathers its nearest dots and sends their cards to a gear.](https://computese.com/images/blog/generative-ai-for-databases/vectors.139ef0f0c6-1536.webp) *Vector search matches meaning rather than exact words, so a question can find a passage phrased quite differently.* [pgvector](https://github.com/pgvector/pgvector) brings this into PostgreSQL. The open-source extension (version 0.8.6 as of September 2026, for PostgreSQL 13 and later) stores vectors in ordinary columns next to the rows they describe, and supports exact search plus two approximate index types. HNSW builds a multilayer graph with the better speed-to-recall trade-off, at the price of slower builds and more memory. IVFFlat divides vectors into lists, builds faster and uses less memory, but has the worse speed-to-recall trade-off. ```sql CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE doc_chunks ( id bigserial PRIMARY KEY, doc_id bigint NOT NULL, region text NOT NULL, body text NOT NULL, embedding vector(1024) NOT NULL /* the size your embedding model returns */ ); CREATE INDEX ON doc_chunks USING hnsw (embedding vector_cosine_ops); /* The five chunks closest in meaning to the question ($1), in one region */ SELECT id, body FROM doc_chunks WHERE region = 'west' ORDER BY embedding <=> $1 LIMIT 5; ``` Three details matter once this runs on real data: - **Index limits.** A `vector` column can store up to 16,000 dimensions, but HNSW and IVFFlat indexes accept up to 2,000 (4,000 with the half-precision `halfvec` type). Check your embedding model's output size before choosing a column type. - **Filters apply after the approximate index scan.** pgvector's documentation gives the arithmetic: with HNSW's default `hnsw.ef_search` of 40 and a filter that matches 10% of rows, only about 4 rows come back on average. Since version 0.8.0, iterative index scans (`SET hnsw.iterative_scan = strict_order;`) keep scanning until enough rows match. - **Hybrid search.** Combine vector search with PostgreSQL full-text search and merge the rankings with Reciprocal Rank Fusion or a cross-encoder, so exact terms such as product codes and names still match. The strongest argument for keeping vectors in the database you already run is governance. The embedding sits in the same row as its text, so joins, transactions, backups and row-level security apply to retrieval exactly as they apply to any other query. A separate vector store needs its own copy of every access rule, kept in step with the source. Other engines build the same idea in: SQL Server 2025 has a native [`vector` data type](https://learn.microsoft.com/en-us/sql/t-sql/data-types/vector-data-type) (up to 1,998 dimensions), BigQuery has [`VECTOR_SEARCH`](https://cloud.google.com/bigquery/docs/vector-search-intro) with vector indexes, and Oracle's Select AI supports RAG over vector stores. For how retrieval fits into a product, see [how to build AI into an application](https://computese.com/artificial-intelligence-and-intelligent-apps/). ## AI help with everyday database work ### Writing and explaining queries Gemini in BigQuery generates SQL from a prompt or a comment in the editor and explains an existing query in plain language. [Copilot in Azure SQL Database](https://learn.microsoft.com/en-us/azure/azure-sql/copilot/copilot-azure-sql-overview) writes T-SQL from a question and draws on dynamic management views, catalog views and Query Store to answer performance questions. Both vendors say the same thing in their documentation: mistakes are possible, so review the output before it reaches production. Google adds that the same prompt can produce different syntax each time, which is one more reason a generated query that matters belongs in version control. ### Query tuning An assistant is good at proposing a rewrite or an index. It cannot know your data distribution or write load unless something measures them, so treat each suggestion as a hypothesis: 1. Capture the current plan and timings with `EXPLAIN (ANALYZE, BUFFERS)` on a copy of production data. 2. Apply the suggested change on the copy and measure again. 3. For a new index, weigh the extra cost on every insert and update against the read gain. 4. Keep the before and after plans with the change request. `EXPLAIN ANALYZE` [actually executes the statement](https://www.postgresql.org/docs/current/sql-explain.html). To measure an `UPDATE` or `DELETE` without changing data, wrap it in a transaction and roll it back: ```sql BEGIN; EXPLAIN (ANALYZE, BUFFERS) UPDATE orders SET status = 'archived' WHERE ordered_at < DATE '2024-01-01'; ROLLBACK; ``` ### Schema design and migrations Models draft a reasonable first schema from a description of the business and write migration scripts quickly. Review them like any other code: keys and constraints, data types and nullability, names that follow your conventions, and indexes for the queries you actually run. Apply migrations through your normal migration tool and pipeline, never by letting an assistant run DDL against production. ### Documentation Documentation is where AI help pays back twice. Databricks can [generate descriptions](https://docs.databricks.com/aws/en/comments/ai-comments) for catalogs, schemas, tables and columns from their metadata, and Genie reads those Unity Catalog comments when it writes SQL, so better descriptions lead to better answers. Databricks is explicit on two points: a person should review each comment before saving it, and the feature should not be relied on to find columns that hold personal data. ## The risks, and the control for each | Risk | What it looks like | Control | | ----------------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Wrong but plausible SQL | A tidy table with the wrong number: a join that double-counts, a calendar quarter instead of a fiscal one | Metrics in a semantic layer, verified queries, visible SQL, an evaluation set | | Too much access | The assistant's account can read every table, or write | Read-only grants, the user's own identity, row-level security and column masks | | Prompt injection through data | A stored note or document tells the model to run a different query | Permissions do the enforcing; retrieved text is treated as data; approval for anything that writes | | Personal data exposure | Names, emails or health details reach the model, its logs or another user | Leave such columns out, mask them, check what each feature sends | | Runaway cost | Full table scans, long conversations, automated loops | Bytes-billed limits, quotas, timeouts and rate limits | ### Wrong but plausible SQL This is the risk that matters most, because nothing flags it. The query runs, the table looks tidy and the number is wrong. Google's BigQuery documentation puts it plainly: generated output can seem plausible and still be incorrect. The survey of the field lists the usual semantic errors: wrong joins, misaligned conditions and wrong aggregations. A common one: ```sql /* Question: revenue by region, April to June 2026 */ SELECT c.region, SUM(o.total_amount) AS revenue FROM orders AS o JOIN order_lines AS l ON l.order_id = o.id JOIN customers AS c ON c.id = o.customer_id WHERE o.ordered_at >= DATE '2026-04-01' AND o.ordered_at < DATE '2026-07-01' GROUP BY c.region; ``` The join to `order_lines` repeats each order once per line, so every order's total is counted once per line. Nothing errors, and revenue is simply inflated. A metric defined once in a semantic layer, with its join path, prevents this class of mistake, and a verified query for the question people ask most removes the guess entirely. Snowflake's verified query repository can record who verified each query and when; Genie calls the equivalent trusted assets. Test the whole setup with an evaluation set of real questions and checked answers before every change of model, prompt or definitions: Genie supports benchmarks for this, and Snowflake runs evaluations against your verified queries. ### Permissions: read-only roles and row-level security Assume the model will, sooner or later, write a query you did not intend. The account it runs as decides what that query can do. Databricks Genie and Microsoft Fabric data agents run generated queries read-only and check data access as the end user. Amazon's Redshift documentation, by contrast, says SQL that would change the database might only produce a warning. If you build your own, enforce the rules in the database: - Grant `SELECT` only, on the tables or views the use case needs. - Run each query as the asking user's identity, so row-level security applies to that person. - Never connect as the table owner, a superuser or a role with `BYPASSRLS`: in PostgreSQL all three normally [bypass row security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html). - If the assistant queries views, create them [`WITH (security_invoker = true)`](https://www.postgresql.org/docs/current/sql-createview.html). By default PostgreSQL checks the underlying tables, and their row security policies, as the view's owner. ```sql /* Analysts' own logins get read access through one group role */ CREATE ROLE analysts NOLOGIN; GRANT USAGE ON SCHEMA sales TO analysts; GRANT SELECT ON sales.orders, sales.region_access TO analysts; /* Each analyst sees only the regions assigned to them */ ALTER TABLE sales.orders ENABLE ROW LEVEL SECURITY; CREATE POLICY own_regions ON sales.orders FOR SELECT TO analysts USING (region IN (SELECT region FROM sales.region_access WHERE member = current_user)); ``` Whatever SQL the model writes, the database returns only the rows for the regions assigned to the analyst who asked. A colleague who asks the same question gets a different, equally correct answer, and neither can talk the model into more. ![One query sheet enters a database table whose rows come in two shades. An orange filter at the table's edge sends each of two laptops only the rows of its own shade.](https://computese.com/images/blog/generative-ai-for-databases/rows.e57085cf82-1536.webp) *The same generated query returns different rows to different people, because the database decides who sees what, not the prompt.* Two PostgreSQL settings add a second layer: [`default_transaction_read_only` and `statement_timeout`](https://www.postgresql.org/docs/current/runtime-config-client.html), set per login role. They are settings, not privileges. The [`set_config()` function](https://www.postgresql.org/docs/current/functions-admin.html) does the same as the `SET` command and can be called inside a `SELECT`, so a generated query could switch them off. For the same reason, never key a row security policy on a session variable that the query it limits could overwrite. The grants and the policies are what enforce. ### Prompt injection through data A model that reads your data also reads any instructions hidden in it. A product review, a customer note or a document chunk in a vector store can contain text written to steer the model. OWASP's Top 10 for LLM Applications lists this as [indirect prompt injection under LLM01:2025](https://genai.owasp.org/llmrisk/llm01-prompt-injection/), and notes that RAG does not fully prevent it. [Researchers who studied LangChain-based database chatbots](https://arxiv.org/abs/2308.01990) (published at ICSE 2025) showed the database version: records poisoned with crafted text made the chatbot generate the attacker's SQL when other users asked innocent questions, and the attacks worked on every model they tested that could write well-formed SQL. Restrictions written into the prompt proved fragile. The defences they proposed start with database permission hardening, then add query rewriting, a second model that validates, and preloading the user's own data into the prompt. > [!WARNING] > Never rely on the prompt to stop the model from reading or changing data. Whatever the account can do, an injected instruction can eventually make the model do. The controls are the ones above, plus two habits. Keep text the model retrieves clearly marked as data and never let it choose tools or targets. Require a person's approval for anything that writes, sends or deletes. It is the same principle as [defending against SQL injection](https://computese.com/best-practices-for-secure-coding/): data must never become code. ### Personal data exposure Ask two questions of any tool: what does the model see, and what is kept? The answers differ by feature. - **Metadata only.** Snowflake says Cortex Analyst uses the semantic model's metadata only to generate SQL, and by default runs on Snowflake-hosted models, so prompts and metadata stay inside Snowflake's governance boundary. - **Metadata that contains data.** Genie uses sample values from selected columns, along with metadata, to infer business logic. Sample values from an email column are personal data. - **Results.** Oracle's `narrate` action sends the query result to the model to describe it; an administrator can disable sending table data for the whole database. - **Training.** Google says Gemini for Google Cloud does not use your prompts or its responses to train its models without permission. AWS says Redshift queries, data and schemas are not used to train a foundation model, and Snowflake says it does not train on customer data. Keep columns with personal data out of the semantic model and the agent unless the use case needs them, and mask them for everyone who does not. Do not count on an instruction in the system prompt to hide data: OWASP's [LLM02:2025](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/) notes that such restrictions may not be honoured and can be bypassed through prompt injection. Log what was sent, and check the obligations of the privacy law that applies to you. ### Cost Generative AI on a warehouse runs two meters: the model and the query. - **Snowflake** bills Cortex Analyst per successful message, plus warehouse time to run the generated SQL. Called through Cortex Agents, the number of tokens also affects the cost, and a conversation's full history is processed again with every new question. - **Databricks** makes [Genie One and Genie Agents free for users](https://docs.databricks.com/aws/en/genie/) through January 31, 2027 (service principals are billed), and has billed Genie Code pay-as-you-go since July 8, 2026. - **BigQuery** [on-demand pricing bills bytes read](https://cloud.google.com/bigquery/docs/best-practices-costs), and a `LIMIT` does not reduce the cost on non-clustered tables. Set maximum bytes billed on the jobs the assistant runs: a query estimated above the limit fails without a charge. Custom daily quotas per user or per project are hard caps. - **Everything else** falls under OWASP's [LLM10:2025, unbounded consumption](https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/), which covers "denial of wallet" abuse: set rate limits and quotas per user, and timeouts on long operations. ## How to deploy generative AI on your data safely Start narrow, and let the database, not the prompt, carry the rules. 1. **Choose one domain and write the questions down first.** Snowflake's own advice is to start a semantic model from the list of questions it should answer. 2. **Define the metrics once in a semantic layer:** the [dbt Semantic Layer](https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl) (built on MetricFlow), Snowflake semantic views, a Genie knowledge store or BigQuery glossary terms. When a definition changes there, every consumer, the assistant included, picks up the change. 3. **Add verified queries** for the questions that matter most, each with an owner and the date it was checked. 4. **Enforce access in the database:** read-only, the user's own identity, row-level security and column masks, and no owner or administrator connections. 5. **Cap cost and time:** bytes-billed limits or quotas, statement timeouts and per-user rate limits. 6. **Build an evaluation set** from real questions with checked answers, and run it before every change of model, prompt or definitions. 7. **Show the working with every answer:** the SQL, the definitions used and whether a verified query produced it. Log the question, the SQL, the user and the cost. 8. **Have a person check before decisions.** A number that goes into a board report, a price or a payment is reconciled against a known figure by someone who can read the SQL. > [!IMPORTANT] > The assistant is a faster way to ask, not a new source of truth. The truth still lives in the tested models and definitions behind it. Most of this is data platform work before it is AI work. Our [data platform service](https://computese.com/services/data-platform/) builds the semantic layer, tested models and role, row and column-level access that a natural-language interface depends on. Our [AI and automation service](https://computese.com/services/ai-automation/) builds assistants grounded in your own documents and live data, with read-only tools and an evaluation set run before every change. For the limits of the models themselves, see [where AI understanding falls short](https://computese.com/ai-limitations-in-understanding/). ## Key terms - **Text-to-SQL (NL2SQL)**: Converting a question written in everyday language into a SQL query, running it and returning the result. Variants generate DAX for Power BI or KQL for log and event data. - **Schema linking**: The step that picks the tables and columns a question needs from the database's metadata, so the model sees only the relevant part of a large schema. - **Execution accuracy**: The main text-to-SQL benchmark score: the share of questions where the generated query returns the same result as a reference query written by people. - **Semantic layer**: Shared definitions of business metrics, dimensions and join paths above the tables, such as the dbt Semantic Layer or Snowflake semantic views, used by dashboards and AI assistants alike. - **Verified query**: A question paired with SQL that a named person has checked. Vendors call them verified queries, golden queries or trusted assets, and assistants reuse them for similar questions. - **Embedding**: A list of numbers that represents the meaning of a piece of text, so that passages with similar meanings sit close together and can be found by nearest-neighbour search. - **pgvector**: An open-source PostgreSQL extension that stores embeddings in ordinary columns and searches them exactly or with approximate HNSW and IVFFlat indexes. - **Retrieval-augmented generation (RAG)**: Answering with a language model after retrieving relevant passages or rows from your own data, so the answer rests on sources you control. - **Row-level security**: A database feature that filters which rows each user can read or change, enforced by the database on every query, including queries written by a model. - **Indirect prompt injection**: Instructions hidden in content the model reads, such as a stored note or a retrieved document, that change what the model does. OWASP lists it under LLM01:2025. ## Common questions ### Can AI write SQL queries accurately? On well-documented databases, the best systems now get most benchmark questions right: as of September 2026 the top BIRD test score is 82.39%, against a human score of 92.96%. On enterprise-scale tasks, the Spider 2.0 paper's baseline agent solved only 21.3%. Accuracy on your own data depends on the definitions and examples you give the system, so measure it with your own questions. ### Which databases let you query data in natural language? As of September 2026: Snowflake (Cortex Analyst, and Cortex Agents, which Snowflake now recommends), Databricks (Genie), Google BigQuery (conversational analytics and Gemini), Microsoft Fabric (data agents), Amazon Redshift (Amazon Q generative SQL in query editor v2) and Oracle Autonomous AI Database (Select AI). On PostgreSQL or MySQL you run yourself, you usually build the same loop from a model API and your own controls. ### Is it safe to connect ChatGPT or another LLM to a production database? Not with a privileged account. Research on LLM database chatbots showed that poisoned records could make the model generate an attacker's SQL, and that restrictions written into the prompt did not reliably stop it. Connect through a read-only role that carries the asking user's identity, with row-level security and timeouts, preferably to a replica or a warehouse rather than the system that takes orders. ### Do I need a separate vector database for AI search? Often not. If your data already lives in PostgreSQL, pgvector adds vector columns and approximate nearest-neighbour indexes next to the rows they describe, so filters, joins, backups and row-level security apply to retrieval too. A dedicated vector store can still make sense for very large collections or specialized features, but it needs its own copy of every access rule. ### Will the AI see our customer data? It depends on the feature. Some send only metadata to the model, but metadata can include sample values from a column; some, like Oracle's narrate action, send query results. Check what each feature sends, keep personal data columns out of the model's context unless the use case needs them, and check the provider's statement on training and retention. ### What is a semantic layer, and why does AI need one? A semantic layer defines your metrics, dimensions and join paths once, above the tables, so every tool computes revenue or active customers the same way. A language model given only table names has to guess those meanings; given the semantic layer, it reuses the definitions your analysts already agreed on. ## Sources 1. [MIT researchers introduce generative AI for databases](https://news.mit.edu/2024/mit-researchers-introduce-generative-ai-databases-0708), MIT News 2. [GenSQL: A Probabilistic Programming System for Querying Generative Models of Database Tables](https://arxiv.org/abs/2406.15652), PLDI 2024 (arXiv) 3. [A Survey of Text-to-SQL in the Era of LLMs: Where are we, and where are we going?](https://arxiv.org/abs/2408.05109), arXiv 4. [Cortex Analyst](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst), Snowflake 5. [Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs](https://arxiv.org/abs/2305.03111), NeurIPS 2023 (arXiv) 6. [BIRD-SQL leaderboard](https://bird-bench.github.io/), BIRD team 7. [Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows](https://arxiv.org/abs/2411.07763), ICLR 2025 (arXiv) 8. [Spider 2.0 leaderboard](https://spider2-sql.github.io/), XLANG Lab 9. [Cortex Analyst Verified Query Repository](https://docs.snowflake.com/en/user-guide/views-semantic/verified-query-repository), Snowflake 10. [Genie Agents concepts](https://docs.databricks.com/aws/en/genie-agents/concepts), Databricks 11. [Conversational analytics overview](https://cloud.google.com/bigquery/docs/conversational-analytics), Google Cloud 12. [Write queries with Gemini assistance](https://cloud.google.com/bigquery/docs/write-sql-gemini), Google Cloud 13. [Fabric data agent concepts](https://learn.microsoft.com/en-us/fabric/data-science/concept-data-agent), Microsoft Learn 14. [Interacting with Amazon Q generative SQL](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-generative-ai.html), Amazon Web Services 15. [Use AI Keyword to Enter Prompts (Select AI)](https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/select-ai-keyword-prompts.html), Oracle 16. [Manage AI Profiles (Select AI)](https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/select-ai-manage-profiles.html), Oracle 17. [pgvector: Open-source vector similarity search for Postgres](https://github.com/pgvector/pgvector), pgvector (GitHub) 18. [Vector data type](https://learn.microsoft.com/en-us/sql/t-sql/data-types/vector-data-type), Microsoft Learn 19. [Introduction to embeddings and vector search](https://cloud.google.com/bigquery/docs/vector-search-intro), Google Cloud 20. [Microsoft Copilot in Azure with Azure SQL Database](https://learn.microsoft.com/en-us/azure/azure-sql/copilot/copilot-azure-sql-overview), Microsoft Learn 21. [EXPLAIN](https://www.postgresql.org/docs/current/sql-explain.html), PostgreSQL Global Development Group 22. [Add AI-generated comments to Unity Catalog objects](https://docs.databricks.com/aws/en/comments/ai-comments), Databricks 23. [Row Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html), PostgreSQL Global Development Group 24. [CREATE VIEW](https://www.postgresql.org/docs/current/sql-createview.html), PostgreSQL Global Development Group 25. [Client Connection Defaults](https://www.postgresql.org/docs/current/runtime-config-client.html), PostgreSQL Global Development Group 26. [System Administration Functions](https://www.postgresql.org/docs/current/functions-admin.html), PostgreSQL Global Development Group 27. [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/), OWASP Gen AI Security Project 28. [From Prompt Injections to SQL Injection Attacks: How Protected is Your LLM-Integrated Web Application?](https://arxiv.org/abs/2308.01990), ICSE 2025 (arXiv) 29. [LLM02:2025 Sensitive Information Disclosure](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/), OWASP Gen AI Security Project 30. [Genie](https://docs.databricks.com/aws/en/genie/), Databricks 31. [Estimate and control costs](https://cloud.google.com/bigquery/docs/best-practices-costs), Google Cloud 32. [LLM10:2025 Unbounded Consumption](https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/), OWASP Gen AI Security Project 33. [dbt Semantic Layer](https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl), dbt Labs