Why FeatureMesh?

FeatureMesh is a platform for business logic. You define named, typed, composable calculations called features in FeatureQL, and they run everywhere: data warehouses, real-time APIs, ML pipelines, and production systems.

What is FeatureQL?

FeatureQL is a language that looks like SQL but solves a different problem. SQL is designed to query tables. FeatureQL is designed to define, share, and compose business logic.

A feature is a single named calculation: "customer lifetime value", "eligible for discount", "days since last order". Features reference other features. The system resolves dependencies, data fetching, and execution automatically. You think in business concepts, not in tables and joins.

Three properties make this work:

Column level composability. The unit of reuse is a single calculation, not a table or a model. Any feature can build on any other feature. This is a fundamentally different granularity from SQL views, dbt models, or semantic layer metrics, and it enables a degree of reuse that those tools cannot achieve.

Safety through types. FeatureQL's type system distinguishes a customer ID from an order ID at the compiler level, even when both are integers. It rejects implicit type coercion across backends. It validates every change against all downstream dependencies before anything runs. A feature that compiles is guaranteed to produce the same result on DuckDB, Trino, and BigQuery.

Write once, run anywhere. The same feature definition transpiles to native SQL for batch analytics on your warehouse and runs in memory for sub-millisecond API serving. No reimplementation, no drift between systems.

What it enables

Consistent logic everywhere. Everyone uses the same definition of "active customer" or "monthly recurring revenue." Not because a wiki page says so, but because the system enforces it. The registry validates consistency on every change; you cannot accidentally break downstream features.

Deep composition. Define customer lifetime value. Build a customer segment on top of it. Use that segment to qualify orders. Create a variant that swaps one threshold to test an alternative. Each piece is independently testable, reusable by anyone in the organization, and replaceable without affecting the rest.

Experimentation without duplication. VARIANT() creates alternative versions of any feature by replacing a specific dependency. The original stays untouched. Compare side by side, roll out gradually, revert by removing the variant. No copy paste, no drift.

Faster onboarding. Data engineers publish verified features. Analysts build on top without understanding the underlying data sources. New team members become productive by composing what exists, not by learning years of tribal knowledge.

A natural interface for AI. FeatureQL's structured vocabulary of named, typed features gives LLMs a dramatically smaller and safer search space than raw SQL against a complex schema. Every AI-authored decision becomes an inspectable, versioned, reproducible artifact in the registry.

How it fits your stack

FeatureMesh is not a replacement for your data warehouse or your SQL. It sits alongside them.

Your BI tools, SQL clients, and notebooks connect through a transparent proxy or embed FeatureQL inside regular SQL. Your backends stay the same. Adoption is gradual: start with one feature, add more over time, no big migration required.

You might not need FeatureMesh

If you're one or two people doing your own analytics, you don't need this. Your SQL files are fine.

FeatureMesh pays off when collaboration, reuse, and consistency start to matter: multiple people building on each other's work, business logic that needs to stay in sync across systems, and pressure to ship faster without breaking things.