AI NewsOpen sourceAnnouncement

HelixDB releases Helix Foundry, a local-first alternative to Palantir Foundry

HelixDB released Helix Foundry, an MIT-licensed local workspace that connects a company's databases and SaaS tools into one ontology and runs AI queries locally.

AI News

Editorial2 min read

LinkedInX
The Helix Foundry Explorer showing accounts, users, invoices, subscriptions, campaigns, SSO connections, and support tickets as one connected graph

Image: HelixDB

Why it mattersA small team can now explore joined-up company data on one laptop, with no vendor contract, no cloud account, and no credentials leaving the machine.

Palantir Foundry sells a connected view of a company's data at a price only large customers pay. HelixDB released Helix Foundry on 7 October 2026, an open-source project that does the same job for a different user: ingest the databases and SaaS tools a company already runs on, suggest one ontology across them, and answer questions in natural language against local snapshots. The project is MIT-licensed, runs on your own computer through Docker, and has collected 589 stars on GitHub in three days.

Ten connectors, one ontology, local snapshots

Connectors cover Neon, Supabase, PlanetScale, PostgreSQL, MySQL, Stripe, WorkOS, PostHog, REST APIs, S3-compatible storage and file uploads for CSV, JSON, JSONL and Parquet, with an ingestion API alongside them. Automatic sync uses native PostgreSQL and MySQL change capture where the database supports it, and scheduled snapshot refreshes otherwise.

The ontology step matches the same customers and records across those sources and stores them as objects and relationships in HelixDB, the vector-graph database the same team maintains. Data lives in immutable Parquet snapshots, with profiles and a schema-drift review, queried by isolated DuckDB processes.

Two in-product surfaces sit above all of this: a Home with key metrics, and an Analyst that answers questions in English and returns the SQL it ran, with citations to the snapshots the answer came from.

Local AI by default

Helix Foundry runs qwen3:4b through Ollama by default. A team can switch to Claude or OpenAI, with keys entered in the browser rather than on the command line. AI-proposed changes to the ontology are tested and wait for a person's review before anything is written. The agent setup command, which the project asks you to paste into a coding agent, installs the stack with approvals at each step and never sees the credentials.

The security model is one person on one laptop

HelixDB is clear about who the product is for. There are no accounts and no sign-in, which means anyone who can reach the app controls every workspace. The app binds to 127.0.0.1 only, the API rejects requests whose Host header is not this machine, generated SQL runs in a DuckDB executor on an internal Docker network with no internet access, and connector and AI credentials are encrypted with a local key from .env. The project tells users not to publish it with a reverse proxy or a tunnel, because the whole model assumes a single trusted operator.

Why one laptop is the point

Open-source alternatives to data-ontology products are rare because the shape of the problem (connectors, modelling, change capture, review) requires a lot of parts to work together before anything is useful. Helix Foundry puts those parts behind one setup script and one Docker Compose stack, with a working ontology on sample data if a user chooses that path during onboarding. For a small team that would never buy Foundry, the choice is now between many unlinked CSV files and a connected graph on one laptop.

Source

Helix Foundry on GitHub. Feature list, security model and connector set: HelixDB's own README. Star count: GitHub API.

SourceHelixDB

This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.

Share
LinkedInX
Start a project