Solutions · Gluesync 2.3
You already speak SQL when you need a precise answer. Sometimes you want to ask first.
AI as SQL puts that ask on Query Forge: one jdbc:gluesync:// connection,
your identity, a normal result row with an answer and an optional SQL draft. You review. You run.
Not another chatbot bolted onto sync. Not a free pass past your permissions.
Coming in Gluesync 2.3
SELECT answer, proposed_sql,
citations, conversation_id
FROM gluesync.ai
WHERE question = ?;Review proposed_sql before you run it.
The problem
DataGrip, DBeaver, JDBC scripts, and Query Forge already carry identity and reach federated schemas. AI as SQL keeps the question and its inspectable result on that governed wire.
The approach
Query the gluesync.ai virtual catalog. Query Forge returns a structured ResultSet
under the caller’s PAT and RBAC, using the model provider configured in your BYO vault.
Eight outcomes · One JDBC surface
Anything that can open a JDBC connection can invoke an LLM as a normal SELECT: Tableau, Power BI and Looker reports, Talend, Informatica and Pentaho jobs, dbt models, Airflow and scheduler steps. Warehouse-native AI functions only reach the data already loaded in that warehouse — this one runs an AI step inside the ETL processes you already have, across the federated estate, without exporting rows to a separate AI service.
any JDBC client Read proposed_sql as a normal result column and inspect the statement before choosing to execute it. The draft is never run automatically.
proposed_sql Receive answer and citations together as an inspectable work product: a plain-language explanation with the references used to build it.
answer + citations Keep a visible trust loop. AI drafts the next SQL statement; you review it and own the side effect of running it.
review before run Use the same Query Forge connection as your federated schemas. Query Studio AI remains a separate door for teams working in the Gluesync editor.
jdbc:gluesync:// Parameterize WHERE question = ? in JDBC scripts, audited jobs, and playbooks authenticated with the caller’s Personal API Token.
WHERE question = ? Combine Query Forge JOINs with FROM gluesync.ai. In Gluesync 2.3, name-in-question grounding matches a whole table, schema, agent, or database name, case-insensitively — never a substring. A unique match grounds the question; a stronger score wins; equal-strength collisions fail closed; no match leaves grounding empty. Explicit pipeline_id and agent_id always win. BYO provider_id selection remains available.
FROM gluesync.ai Pass conversation_id into the next question to continue the thread while keeping each response structured as a ResultSet.
conversation_id How it fits
Available today
The shipped federated JDBC gateway and the wire AI as SQL builds on.
Explore →Gluesync 2.3
The gluesync.ai virtual catalog that returns an answer and optional SQL draft.
Explore →In the editor
The Gluesync editor helper for drafting SQL from visible schema context.
Explore →Gluesync 2.3
The BYO provider vault prerequisite for selecting the model behind the request.
Explore →What does not change
proposed_sql is returned and never auto-runs.FAQ
Answers about asking natural-language questions through Query Forge and reviewing generated SQL before it runs.
AI as SQL lets a JDBC client send a natural-language question to the gluesync.ai virtual catalog and receive a structured ResultSet with an answer and an optional SQL draft.
No. proposed_sql is returned as a reviewable result column and is never run automatically; the caller decides whether to execute it.
The ResultSet includes an answer, citations, an optional SQL draft, and a conversation_id for follow-up questions in the same session.
Yes. It uses the Query Forge JDBC connection, so it works from DataGrip, DBeaver, JDBC scripts, and other clients that already speak JDBC — including BI and ETL tools.
No. AI as SQL is coming with Gluesync 2.3. Teams can book a demo or request early access to preview the workflow.
Gluesync 2.3
AI as SQL is coming with Gluesync 2.3. Preview this new SQL workflow with our team.