FeatureMesh in the enterprise

FeatureQL decouples business logic from the pipelines that precompute it and from the engines that run it. That decoupling is what lets a data team deliver impact without an organizational project.

Now, in analytics. One person or one team can start. Pipelines, BI (business intelligence) tools and backend code stay as they are. No other team has to agree first.
Next, in production. The same definitions serve applications and are improved by experiment. AI agents can run that loop within limits you set, without a human bottleneck.

Horizon	What you do	Benefit	Who starts it
Analytics	Give your AI assistant FeatureQL	Text-to-SQL answers you can trust	One analyst or data scientist
Analytics	Write the gold layer in FeatureQL, with caching	New metrics without new pipelines	The data team
Analytics	Keep every KPI and rule in one registry	Clear audits and risk management	The data team
Analytics	Run the same definitions on several engines	Lower compute costs	The data platform team
Production	Serve rules as APIs from the registry	Rule changes without an engineering release	A product team, with engineering
Production	Let agents test and roll out rule changes	Continuous optimization, without a human bottleneck	Product, data and engineering

What every benefit builds on

All six start from the source mapping. Someone declares the entities (customer, order, and so on) and maps warehouse tables to source features with EXTERNAL_COLUMNS.

An assistant with the FeatureMesh tools can draft this mapping. Someone who knows the data reviews it. It is written once, and every benefit below builds on it.

Start with analytics

Built for AI assistants

Today. Text-to-SQL prototypes are usually run by one or two people. They keep SQL snippets and markdown files that describe tables, joins and metric definitions. They paste these into the model's context, and the model writes SQL against the schema. A wrong join or a wrong rollup still returns a number. Nobody sees the error unless they reread the SQL.

With FeatureMesh. The metric definitions are features in the registry, not prose in a markdown file. The model composes published features by name. It writes no join and reads no row:

RETURN CUSTOMER_ID, CUSTOMER_SEGMENT, CUSTOMER_AT_RISK, CUSTOMER_LTV
FROM FM.ECOMM
FOR CUSTOMER_ID := BIND_COLUMNS(...)
WHERE CUSTOMER_AT_RISK

Three properties replace the snippets and the markdown files:

A vocabulary the model can query. SHOW FEATURES, SHOW FUNCTIONS and the help corpus list what exists, with signatures and runnable examples.
Checks before execution. A wrong join, a unit mix or an illegal rollup fails to compile. With generated SQL, the same mistakes return a number.
Errors written for a repair loop. Each error has a stable code, a location, the feature it concerns and, where one exists, a repair that compiles. The model follows the compiler instead of guessing.

The reviewer's question changes from "is this SQL correct" to "is this the right definition".

What it takes. One person, a pip install featuremesh, the mapping of the tables the questions need, and a local MCP (Model Context Protocol) server. MCP is the standard way to give an assistant tools. Here the tools are validation, diagnosis, execution and help. No account is needed, and FeatureMesh does not receive query rows. See FeatureQL with AI .

Self-service analytics without a pipeline per question

Today. Business logic sits in gold tables built by scheduled pipelines. Checking a new definition, or a variation of an existing one, means a pipeline change and a backfill. Making a slow dashboard faster means another table and another job. Each of these requests waits for the data team.

With FeatureMesh. The split between layers changes:

The silver layer keeps cleaned tables with little business logic. They are mapped once as sources.
The gold layer is FeatureQL. Its features are computed from silver tables when they are queried.

A new metric is a new feature, available as soon as it is created. A variation of an existing metric is a VARIANT(), and the original stays in place. Nothing is backfilled.

BI tools reach features without change, through three doors:

Hybrid queries. FEATUREQL(...) blocks inside ordinary SQL.
Persisted views. CREATE VIEW FMV.schema.table compiles a FeatureQL query into a SQL relation. JDBC (Java Database Connectivity) clients such as Tableau, Power BI, Looker or Superset discover and scan it like a table.
The transparent proxy. It presents itself as Trino, so a SQL client connects as it would to a Trino cluster.

See SQL interoperability .

Speed, decoupled from the definition. Expensive features are precomputed, and queries read the result automatically:

Your orchestrator (Airflow, Dagster, cron) precomputes the feature into a table, with the same FeatureQL query.
It registers the table with CREATE CACHES.
Later queries read the cache whenever that saves work. The dashboard query does not change.

A cache is tied to the logic of the feature. When the definition changes, old caches stop matching and are never read. A dashboard cannot show a number computed with an outdated rule.

So pipelines still run, but they are no longer the definition. They are an optimization behind it. Adding or removing a cache changes the speed of a query, not what it means. See Datakey caches .

One place for business logic

Today. The same rule lives in views, semantic-layer configuration, backend code and wiki pages. Each copy has its own owner and its own release cycle. A reviewer reconstructs one rule from several places.

With FeatureMesh. A rule is a named feature with explicit dependencies. It is reviewed as a unit. The registry does two things around it:

It validates every CREATE, REPLACE and DROP against the features that depend on it. A change in one team's namespace cannot break a feature in another.
The managed registry keeps a history of definitions. SHOW REVISIONS lists it, AS OF reads a past revision, and ON BRANCH tries a change without writing to main.

Two audit questions then have direct answers:

Which rule produced this number or this decision? The persisted feature and its dependency tree. Both can be inspected.
Can it be reproduced? The same definition on the same data gives the same result. SCD_AT_TIME and ACCUMULATION_AT_TIME return the state of your data at a past moment. AS OF returns the definition that was live at that time.

This usually starts with KPIs (key performance indicators) in analytics. The same object later carries lending, insurance or healthcare rules in production. Your approval workflow gets one reviewable object per rule.

The same definitions on several engines

Today. Each engine has its own SQL dialect. Moving a workload to a cheaper engine means rewriting the SQL and checking that the numbers did not change. So workloads stay where they were first written, often on the most expensive engine.

With FeatureMesh. Definitions are written once. The compiler emits SQL for DuckDB and Trino in batch, and for DataFusion in serving.

Where engines differ (dates, JSON, nulls, division, time zones), the generated SQL is normalized so the result matches.
Where an engine lacks a capability, compilation fails with an error that names it. It never returns a different number.
A conformance suite runs the documentation examples on each backend.

Each workload can then run where it is cheapest. Cache builds, exploration and repeated dashboard queries can run on DuckDB, on a single machine, instead of a paid warehouse cluster. Large scans run on Trino. Moving a workload does not touch the definitions.

See Same answer across backends .

Then move to production

The two benefits below reuse the definitions built for analytics. They add components that you operate. See What you run .

A backend for rule-heavy projects

Today. Eligibility, pricing tiers or client-specific configuration live in backend if statements. Operations teams know the rules. They still wait for an engineering release to change a threshold.

With FeatureMesh. The rule is a feature. A PREPARED_STATEMENT turns it into an endpoint: a key goes in, a decision comes out. The application depends on one thing, the id of the endpoint.

Thresholds are their own named features. A change is a small, reviewable diff in the registry.
REFRESH deploys the new version behind the same id. The application is not redeployed.
The output type of the statement is the contract. The logic can change. The shape cannot.
Client-specific behavior is a VARIANT() of the shared rule, not a branch in application code.
The rule that was backtested in batch is the rule that is served.

Serving is a lookup by key. Heavy aggregations are computed in batch, written to a low-latency store such as Redis, and read from there.

See Real-time serving .

A loop for improving the business

Typical decisions are eligibility, pricing rules, promotions and personalization, with or without a machine learning model. When a model is involved, the same feature definitions feed training and inference, so the two do not drift apart.

Today. Experimentation usually spans three systems. An experimentation tool assigns users, backend code implements the treatment, and a warehouse measures the outcome. Each has its own definition of the metric.

With FeatureMesh. The loop runs on one set of definitions:

Propose an alternative with VARIANT(). It differs from the original only in the dependencies it replaces.
Backtest it in batch against history, next to the original. No user is exposed.
Roll out with GRADUAL_ROLLOUT() on the serving path. Assignment uses HASH01(), so the same customer always lands in the same arm.
Measure in batch with the same feature definitions.
Promote or drop. A promoted result is a registered feature that the next experiment can build on.

The rule that was backtested is the rule that is served. The metric that judges it is the metric the dashboards show.

With an agent in the loop

A language model can run this loop: propose variants, backtest them, roll them out and explain the results. It works from a typed vocabulary it can query, and the compiler rejects invalid combinations. See FeatureQL and language models .

People set the limits once, based on one principle: an agent may change what is decided, not how it is judged. In practice the registry is split by write permission. The agent writes in the namespace that holds decision features and their variants. It only reads metrics, guardrails, rollout limits and source mappings.

Set by people	Done by the agent, within those limits
Which decisions are delegated	The decision logic in its namespace
Target and guardrail metrics, with stop thresholds	Proposing variants
The dependencies it may replace	Backtesting on history
Maximum rollout share and speed	Rolling out within the caps
Statistical rules for promotion	Reading and explaining results
The override that restores the current rule	Recommending promotion or retirement
Who approves promotion

Promotion can be automatic once the rules are met, or stay with a person for regulated decisions. That is a setting.

FeatureMesh provides the primitives (VARIANT, GRADUAL_ROLLOUT, HASH01, lifecycle statuses, namespaces, the revision history) and the audit trail. You configure the permissions, the thresholds and the override.

Running it in an organization

Roles

The work divides between mapping sources and composing what is mapped.

Data platform engineers own the source mapping. They declare entities and map tables. Everything else builds on this layer.
Analysts and data scientists compose. They query published features, build new ones on top, and test alternatives with VARIANT(). The query surface resembles SQL.
Product owners and compliance reviewers read. A threshold or an eligibility rule is a named feature with explicit dependencies, so it is reviewed as a unit.

Namespaces keep these roles independent. Each team publishes features in its own namespace and builds on features that other teams have published. Prototyping needs no permission.

Change management

Every CREATE, REPLACE and DROP is validated for type compatibility, dependency existence and cycles before it takes effect. A change that would break a dependent is refused. Around that:

EXPLAIN (FIELDS (MUTATION_DRY_RUN)) reports what a change would touch, without writing.
Lifecycle statuses (DEV, BETA, ACTIVE, DEPRECATED) mark maturity.
The managed registry keeps the revision history. See Catalog revisions and Branch overlays .

The registry checks structure. Your release process decides what gets approved, and regression tests pin the business numbers that matter.

Checking source declarations

The compiler does not read data. Its guarantees follow from the declarations made at the source, and two of them carry most of the risk:

BIND TO names the lookup key. Two source rows with the same key fan out, and nothing reports it.
DETERMINED BY states that a value repeats on finer rows. It is not checked against the table.

A false declaration gives a wrong number with no error. The check is an ordinary query on your warehouse, such as a uniqueness test on the mapped table. Teams run it in CI next to the SLT files, or on a schedule that suits the data. Source declarations are treated like schema assumptions: stated in one place, tested separately, and owned by the team that wrote them. The assumptions and the check for each are Data contracts .

What you run

Component	When it is needed	Who runs it
Local registry and compiler (pip package)	From the start	One engineer, on a laptop
Shared registry	When features are shared across teams, or for caches	Managed by FeatureMesh, configured by you
Transparent proxy	When BI tools should reach features without change	You
Cache builds	When a dashboard feature is too expensive to compute per query	You, on your orchestrator
Serving (embedded DataFusion, or Kubernetes at scale)	When features are served at request latency	You
Materialization jobs	When a served feature depends on a heavy aggregation	You, on your scheduler

The compiled SQL runs on your warehouse, with your tuning. Real-time features run on DataFusion, in a process you operate.

Adoption and exit

Starting. The pip package ships a local registry, and featuremesh[serving] adds an embedded serving backend. Compilation and execution run locally. No query text or row data is sent to FeatureMesh. See the Python library setup .

Growing. Adoption is feature by feature. FeatureQL embeds in regular SQL, so one feature can be used in one query while everything else stays as it is. When features become shared, the same definitions move to the managed registry without a rewrite.

Leaving. Features compile to standard SQL that you can read and keep.