Most SQL chatbot demos make me optimistic for about 30 seconds.
Then the practical questions arrive:
- Which tables did it use?
- Did it understand what "revenue" means in our company?
- Can I see the SQL?
- Can I replay the analysis later?
- Did the model ever see credentials?
- Can I reuse the chart, table, or report somewhere else?
And suddenly the magic starts to look a lot like a prototype.
That is the problem we are trying to solve with DataFoundry.
DataFoundry is an open-source AI workbench for data analysis. It turns a natural-language question into a governed data task: schema inspection, semantic alignment, read-only execution, SQL audit, artifacts, charts, reports, and replayable run history.
datagallery-lab
/
datafoundry
DataFoundry is an open-source AI workbench for data analysis, unifying data sources, knowledge, tools, and agent runtime into a governed workspace for interactive analytics.
DataFoundry
An enterprise-grade Data Agent workbench — it reads business definitions through unified semantics, runs complex multi-table, multi-step analysis inside read-only boundaries,
and keeps every step auditable and replayable, turning one question into a trustworthy analysis
28 datasource types out of the box · Enterprise semantics & context · Self-hosted · Multi-model · Fully auditable
English · 简体中文
Quick Start · Docs · Supported Data Sources · Roadmap · Contributing
🤔 What Is DataFoundry
When teams let AI query enterprise databases, the real worry is never "can the model write SQL." It is: does it understand business definitions? Could it mutate production data? Could credentials leak into context? Can a conclusion be verified after the fact?
Most tools reduce the problem to prompt → SQL → answer — impressive in a demo, dead on arrival in the enterprise. DataFoundry takes a different path: it puts the agent inside a semantic,…
The problem: data analysis is not a chat message
A lot of Data Agent products follow the same pattern:
prompt → SQL → answer
That is great for demos.
But real data analysis usually looks more like this:
ask → inspect schema → clarify metric → query → check result → drill down → compare → explain → save output → review later
The final answer matters, but the path matters too.
For example, if someone asks:
Why did revenue drop last month?
A useful agent may need to:
- find the right datasource,
- inspect table schemas,
- resolve business definitions,
- generate SQL,
- run joins safely,
- compare time periods,
- detect outliers,
- create intermediate tables,
- draw a chart,
- explain the conclusion,
- and leave evidence that someone else can review.
That is not a one-turn Q&A problem. It is a workflow problem.
So we stopped thinking about the agent as a chatbot and started thinking about it as something closer to a data workbench.
The goal is not to make databases better chat partners. The goal is to make data analysis controllable, inspectable, and reusable.
What we built
DataFoundry puts the agent inside a governed workspace for data tasks.
Instead of only returning text, each run can leave behind:
- SQL queries,
- event streams,
- schema inspection steps,
- table outputs,
- charts,
- reports,
- files,
- and replayable task history.
The current project includes:
- Web workbench for interactive data tasks
- TUI for terminal and remote-server workflows
- Data Gateway for controlled datasource access
- 28 datasource types out of the box
- OpenAI-compatible model support
- read-only execution by default
- SQL audit, row limits, timeouts, and masking
- artifacts and file outputs that do not disappear into chat history
That last point is important. If an agent produces a useful table, chart, or report, it should become an asset — not a paragraph buried in a conversation.
Natural language is only the entry point. The useful part is the task lifecycle around it.
Why not just use a coding agent?
Coding agents are great. I use them too.
But databases have a different risk profile from code repositories.
A coding agent works with files, tests, diffs, commits, and pull requests. A data agent works with datasources, schemas, credentials, permissions, metrics, SQL, intermediate results, and business conclusions.
Those need a different runtime boundary.
With DataFoundry, the model does not need raw database credentials. Datasource access goes through Data Gateway, which is designed around read-only execution, SQL guardrails, row limits, timeouts, masking, and audit records.
In other words:
The agent can work.
The data boundary still belongs to the system.
The model gets governed context. Credentials and datasource execution stay behind the runtime boundary.
The part I care about most: replayability
When an AI system gives a data answer, the most important question is not always:
Is this answer impressive?
It is often:
Can I trust how it got there?
DataFoundry treats every analysis as a run.
A run has state, steps, tool calls, SQL, outputs, and artifacts. That means you can inspect the process after the fact:
- Which tables did the agent inspect?
- Which fields did it select?
- What SQL did it run?
- Was the query limited, masked, or truncated?
- Which output became the final chart or report?
This makes the experience feel less like "the AI said so" and more like a task that can be reviewed, debugged, continued, and shared.
For teams, that is where adoption usually begins.
The longer-term direction: datagraph
The most interesting data context is often not written down anywhere.
It lives in repeated questions, old SQL, analyst habits, naming conventions, metric definitions, dashboard logic, and team-specific language.
That is why we are exploring the idea of a datagraph: a semantic layer that grows as people use the workbench.
Each analysis should not only consume context. It should also leave context behind:
- table relationships,
- field meanings,
- metric definitions,
- common business questions,
- useful query patterns,
- evidence trails,
- lineage,
- and policy hints.
The next run should not start from zero.
The workbench should understand the business a little better after every useful analysis.
Try it locally
You do not need to prepare a database just to try the basic flow. DataFoundry includes a built-in DuckDB demo datasource.
git clone https://github.com/datagallery-lab/datafoundry.git
cd datafoundry
npm install
cp .env.example .env
cp apps/web/.env.example apps/web/.env.local
npm run dev
Then open:
http://127.0.0.1:3000/data-tasks
Try asking:
Show me the tables in this datasource and explain the main fields of each.
If everything is configured correctly, you should see the full chain:
schema inspection → read-only SQL → SQL audit → table output → replayable run history
After that, try connecting your own data stack: PostgreSQL, MySQL, CSV, Excel, Snowflake, BigQuery, ClickHouse, MongoDB, Redis, Elasticsearch, and more.
What kind of feedback we want
DataFoundry is still moving quickly, and we would love feedback from people who are building or using:
- internal data copilots,
- BI agents,
- analytics workbenches,
- Text-to-SQL systems,
- data governance tools,
- semantic layers,
- AI product runtimes,
- or self-hosted enterprise AI tools.
Especially useful feedback:
- Which datasource should we improve next?
- What does your real analysis workflow look like?
- What would make you trust an AI-generated SQL result?
- Which audit or replay features are missing?
- What should the datagraph store?
- Where does the UX still feel too much like a chatbot?
If you have ever built a Text-to-SQL demo that looked great but became hard to trust in real work, I’d love your feedback. Issues, PRs, Stars and brutal comments are all welcome.
If you do not want to star it yet, give us one hard question in the comments: what would make you trust or reject an AI-generated SQL result?
Top comments (2)
I’m especially curious about how people here think data agents should handle replayability.
For teams building BI copilots or Text-to-SQL tools:
Some comments may only be visible to logged-in visitors. Sign in to view all comments.