DataFoundry: a self-hosted workbench that puts a data agent inside read-only, replayable boundaries
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.
At a glance
- What is it?
- DataFoundry (repository datagallery-ai/dataagent) is an Apache-2.0 TypeScript workbench that wraps an LLM agent in semantic definitions, read-only query policy and a persisted event stream. The design is aimed at enterprise analytics, but the deploy path is Linux-only and the project labels itself early.
- Who is it for?
- Adopt DataFoundry if you need a self-hosted, Linux-deployed agent whose SQL, tool calls and event stream are persisted and replayable, and if you can maintain the semantic definitions yourself. Do not adopt it if you need native Windows or macOS deployment, a Docker or Compose artifact, or a project past its stated early stage.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem DataFoundry addresses is not SQL generation
The README states the concern directly: when teams let AI query enterprise databases, the worry is not whether the model can write SQL. It is whether the model understands business definitions, whether it could mutate production data, whether credentials leak into context, and whether a conclusion can be checked afterwards. Those are four separate failure modes, and a prompt-to-SQL loop addresses none of them. The README's own framing of the common alternative is blunt: "impressive in a demo, dead on arrival in the enterprise."
The intended user is a data or platform team inside an organisation that already has a warehouse and a modelling convention. Terms like GMV and retention are assumed to exist as approved definitions somewhere, and DataFoundry's job is to resolve those terms to specific tables, fields and definitions rather than letting the model guess joins. A solo analyst with a single Postgres database and no metric layer gets little from the semantic machinery, because there is nothing to centralise.
How a question becomes a governed run: semantics, read-only boundary, event stream
Three mechanisms are visible in the material. The first is a semantic layer that holds schema, metric definitions and field relationships in one place, so a business term resolves to enterprise-approved tables and fields. The v0.2.0 notes extend this with an optional external DataLink service, connected over MCP, that maps tables and columns to business concepts, entities, joinable paths and confidence-scored relationships. DataLink is explicitly not started by the deploy script; it is a separate component you connect later.
The second is the execution boundary. The README describes read-only queries, credential isolation, field masking, row limits and timeouts as defaults rather than options you switch on. That ordering matters: the safe path is the one you get without configuration.
The third is the record. SQL, tool calls and event streams are persisted and replayable, and v0.2.0 adds a semantic Trace DAG for inspecting checkpoint-backed run structure. The agent runtime is Mastra and the event stream follows AG-UI, with a terminal client built on Ink. Sessions are branchable: you can keep several running, queue follow-up prompts, restore completed work, and branch from an earlier question or checkpoint without overwriting the original path. Follow-up questions can reference a whole output or a selected table or text region, and that resolved evidence is carried into the run context with diagnostics. The net effect is that an answer arrives with the path that produced it, which is the part a plain chat interface throws away.
Installing it: deploy.sh, no Docker, no npm run dev
The README is unusually explicit about what not to do: do not run npm run dev, and Docker or Compose is not provided in this release. The recommended path is the one-click script on Ubuntu or Debian, which generates configuration, installs dependencies, builds the Web, API and TUI targets, then starts Web and API as a detached background process that survives closing the terminal.
git clone https://github.com/datagallery-lab/datafoundry.git cd datafoundry ./deploy.sh
The script is interactive unless a complete .env already exists, in which case it skips the configuration questions. To change ports or the public URL later, with secrets preserved and .env backed up first:
./deploy.sh deploy --reconfigure
Day-to-day management is covered by ./deploy.sh status, start, stop, logs and doctor. The TUI is built but is a foreground client, so it does not stay running with the stack; start it separately with ./deploy.sh tui or npm run start:tui, and the API must already be up. No model key is needed during deploy. You open http://127.0.0.1:3000/login, register or sign in, create an OpenAI-compatible model profile, then go to /data-tasks. On a remote host you set AUTH_PUBLIC_BASE_URL. The README states plainly that native Windows and macOS are not supported.
The datasource list is wide; the deployment surface is narrow
The advertised figure is 28 datasource types out of the box, spanning PostgreSQL, MySQL, Snowflake, BigQuery and ClickHouse through to MongoDB, Redis and Elasticsearch. The authoritative list is docs/en/reference/supported-datasources.md, and that file, not the headline number, is what you should check against your own stack. Breadth across relational, document, key-value and search stores suggests a connector abstraction rather than per-engine query planning, though the material does not describe how each connector is implemented.
The counterweight is deployment. A Linux-only, script-driven install with no container artifact is a real constraint, not a footnote. Teams whose infrastructure is Kubernetes-first, or whose operators expect a Compose file they can read before running anything, will find that deploy.sh is doing a lot of work they cannot easily audit in advance. The script is the deployment contract, and it assumes a host you control rather than an orchestrator. The README also notes that if a complete .env already exists, interactive deploy skips the configuration questions, which is convenient on a second run and a trap on the first if the file was copied from elsewhere. Run ./deploy.sh doctor before trusting a stack you did not watch being built.
Where DataFoundry is the wrong tool
Two cases stand out. The first is the team that wants a hosted, zero-install analytics assistant. DataFoundry is self-hosted by design, and that is the point: data stays inside your boundary. If you are not prepared to run and patch a server, the architecture works against you rather than for you.
The second is the team without a semantic layer and no appetite to build one. The semantic definitions are the mechanism that produces the accuracy claim, and they are also the maintenance burden. Metric definitions drift, and DataFoundry gives drift a single place to live rather than removing it. If nobody owns the definitions, the agent resolves terms against stale ones with more confidence than a free-form prompt would.
The project's own status badge reads "early but usable," and the release history supports that reading: v0.1.0 landed on 2026-08-29 and the README already documents v0.2.0 behaviour. A single release at that distance is not a track record. Nothing in the supplied material describes a migration or upgrade path between versions, so treat the .env backup that ./deploy.sh deploy --reconfigure performs as the only documented rollback aid.
Against a plain text-to-SQL pipeline
The obvious alternative is a thin text-to-SQL chain: take a question, dump the schema, call a model, execute the SQL, return rows. That approach is faster to stand up and needs no semantic definitions, no run store and no policy layer. Its difference from DataFoundry is not accuracy on simple questions. It is what happens after the answer arrives. A text-to-SQL chain typically leaves you with a result set and a prompt, and reconstructing why the model chose a join means re-running it.
DataFoundry trades that simplicity for persistence. The run context, the tool calls and the event stream are stored, follow-ups carry resolved evidence forward, and sessions branch rather than overwrite. If your questions are one-shot lookups, that machinery is overhead. If your questions are multi-table and multi-step, and someone will later ask why a number changed, the stored path is the product.
A second comparison is the semantic layer itself. Vendors in that space focus on defining and serving metrics to BI tools. DataFoundry uses definitions as grounding for an agent and adds an optional DataLink service to supply confidence-scored relationships. The material does not say how DataLink's mappings are produced or validated, so that confidence score is something to inspect on your own data rather than take on trust.
Licence, maintenance and what to verify before adopting
The repository is Apache-2.0. That permits commercial use and modification and includes a patent grant, and it requires that you preserve notices and state changes. It is a permissive licence, not a copyleft one, so it does not oblige you to publish modifications. This is a description of the licence text, not legal advice; if you plan to redistribute DataFoundry inside a product, have counsel read the NOTICE and attribution requirements.
The maintenance cost sits in three places. Semantic definitions need an owner. The model profile needs review, since any OpenAI-compatible provider works (the README names Qwen, DeepSeek and GPT) and the trade-off between security, cost, latency and quality is yours to make per scenario. And the deployment itself needs attention, because the upgrade path between releases is not documented in the material and the stack runs as a detached process rather than under a supervisor the README describes.
What to verify first, concretely: confirm your engine is listed in docs/en/reference/supported-datasources.md; run ./deploy.sh doctor on the target host; and complete the model connection test in the Web UI, which v0.2.0 lists as a production-facing feature. Those three checks cover the datasource, the host and the model before any analyst depends on the output.
Editorial conclusion
Adopt DataFoundry if you need a self-hosted, Linux-deployed agent whose SQL, tool calls and event stream are persisted and replayable, and if you can maintain the semantic definitions yourself. Do not adopt it if you need native Windows or macOS deployment, a Docker or Compose artifact, or a project past its stated early stage. Before committing, verify three things against your own environment: that your datasource appears in docs/en/reference/supported-datasources.md, that ./deploy.sh doctor reports a clean stack on your host, and that your chosen OpenAI-compatible provider passes the model connection test in the Web UI.
Community notes