Helix Foundry had 836 GitHub stars in MrKeyoor's October 10 scouting snapshot, three days after the repository's recorded creation. Its useful developer distinction is buried below the local-AI pitch: the suggested data ontology is computed without a language model. The discovery code matches keys and measures value overlap to propose entities and relationships. AI can describe that structure afterward. That division makes the suggestion easier to inspect before it becomes the basis for an answer about customers or revenue.
The Apache-licensed project runs a data workspace on your computer using HelixDB and DuckDB. It connects databases and services such as Stripe and PostHog, imports snapshots, and presents linked records alongside an assistant that answers questions through executed SQL. The star count records attention at one collection time. The reason to examine the project is the boundary it draws between assembling data and asking a model to explain it.
Matching records comes before explaining them
An ontology here means named kinds of records, such as customers and subscriptions, plus the relationships between them. Foundry's matching implementation looks for usable keys, reads declared foreign keys, and compares candidate columns across datasets. It has explicit safeguards against treating coincidentally overlapping integer IDs as proof that two tables contain the same people. Proposed merges also produce notes showing how many records match and how many remain unmatched.
That behavior has a checkable example in the ontology tests. One test requests a suggestion before a model provider is ready, then enables a provider and asks AI to describe it. The assertions check that the entity memberships and link IDs remain unchanged. The model's input for that description contains the suggested structure rather than dataset rows. These are checked-in test expectations, not an independent measurement of matching accuracy.
Another test confirms the suggestion and replaces the model call with a function that throws if invoked. The build is expected to finish and publish anyway. A separate case covers a dataset without a usable key: it produces no ontology entities and falls back to a row-count overview. Those test cases describe a useful failure boundary. A missing identity column doesn't become an invitation for the model to invent one.
Confirmation changes what can be published
The guided-setup specification lets you rename or exclude suggested entities before confirming the ontology. Confirmation starts a build that publishes the validated workspace automatically. There is no separate review page for that setup path. A build requested from a goal without a confirmed ontology still becomes a proposal awaiting review, so the point where you approve the structure matters.
Publication also checks whether the inputs have changed. The same setup document says the input signature includes immutable dataset versions, pending schema changes and incomplete imports. The commit checks the proposal hash and published generation as well. A suggestion made against yesterday's snapshot should therefore require more than a repeated click if today's data has changed its basis.
For later work, the developer API exposes proposal validation, publication by hash, rejection and rollback. Record edits have preview and execution endpoints, with revisions or hashes and idempotency keys tying execution to the reviewed change. Its guidance treats HTTP 409 as a reason to refresh and review. Blindly retrying a stale approval can defeat the protection the interface is trying to provide.
SQL executes against bounded inputs
The executor source loads declared Parquet snapshots into DuckDB, checks that generated SQL begins with SELECT or WITH, and uses DuckDB's statement parser to reject multiple statements. It then disables external access and locks the configuration before evaluating the query. Extension auto-installation and automatic loading are disabled when the database instance is created.
This gives a reviewer a specific execution boundary to investigate. The query sees the snapshots supplied to its job, and the executor checks those input identifiers before constructing paths. It also profiles results, including null counts and distinct values. The same implementation identifies candidate primary keys as columns with no nulls and one distinct value per row. Those checks establish properties of the data; they cannot decide whether a customer definition matches your business.
Container settings add another boundary. The Compose configuration puts the executor on an internal network, drops Linux capabilities, and sets a 2 GB memory cap and a 128-process limit. Only the application publishes a port, bound to 127.0.0.1. Its Ollama service also sets OLLAMA_NO_CLOUD=1. These are inspectable deployment settings, rather than a claim that every possible installation has been security-tested.
Local data still needs a provider decision
The default inference option is Qwen3 4B through Ollama. According to the feature guide, Claude and OpenAI are explicit alternatives, with no automatic fallback between providers. Hosted-model context uses bounded schemas, profiles and samples. Detected sensitive columns in samples are masked by default, unless the API-only allowRawData setting is enabled. The guide calls that detection a heuristic, which leaves a practical review task for anyone connecting sensitive datasets.
The underlying data model is versioned. The guide separates immutable imported snapshots from workspace record edits, so correcting a record locally does not update the source system or alter the original snapshot. Schema drift is staged for review. For a developer investigating a surprising result, this distinction helps locate the disagreement: it may be in the imported version, the transformation, or a later workspace edit.
The application serves one person and has no sign-in. The API's authentication rules treat a request without an Authorization header as the local owner of every workspace. Scripts use revocable workspace tokens, and invalid tokens receive 401 rather than owner access. This design makes the loopback binding a requirement for adoption. The operations documentation explicitly forbids exposing the app through a proxy, tunnel or port forward.
Change capture still rebuilds snapshots
Foundry prefers native PostgreSQL or MySQL change capture when permissions allow it. The operations guide explains that several commits can be coalesced into one snapshot import. It does not apply each row change directly to the analytical store. The existing two-million-row import limit remains relevant, and source-side WAL or binlog retention needs monitoring. For a large, busy table, receiving change events and having a current analytical result are different milestones.
Operating the local stack also means keeping its state. The backup procedure stops writers and HelixDB, archives data volumes, and saves the encryption configuration before restarting services. Losing that encryption key makes stored connector credentials unrecoverable. Model weights can be downloaded again and are excluded from application backups. Failed previews can consume disk because this MVP has no automatic artifact garbage collector.
Trying it requires Docker Compose v2 and several GB for the initial images and model download. The installation runbook offers a bundled Ollama path and a native Ollama path for Apple Silicon with Docker Desktop. It also makes the user's browser the place to enter database credentials and model API keys. A setup agent should finish by checking application health and providing the local URL; it doesn't need those credentials in its conversation.
The published measurements have a narrow scope
The project's validation notes report September 23 and 24 development runs on an M1 Pro machine with 16 GB RAM. One benchmark converted a million NDJSON rows to Parquet in 472 milliseconds. A separate analytical workload used 25 concurrent HTTP clients and two executor slots, with a median response including queue time of 1,690 milliseconds. Inference was excluded, and the reported 149 MB RSS belonged to the benchmark client, not the full platform. MrKeyoor has not reproduced those runs.
Next, watch for measurements of the whole installation under sustained imports and inference. The maintainers' remaining-validation list leaves peak-memory certification for both the 16 GB target and an 8 GB installation unfinished, and says live hosted-provider checks lacked credentials. For an initial trial, inspect unmatched records before trusting an aggregate. Foundry supplies a deterministic starting structure; the unresolved test is whether that structure holds up on your own inconsistent data.