Why FeatureMesh?
FeatureMesh is a platform for business logic. You define named, typed, composable calculations called features in FeatureQL, and one definition runs in two places: transpiled to native SQL on your warehouse for batch analytics, and on DataFusion for real-time serving.
What is FeatureQL?
FeatureQL looks like SQL at the expression level and solves a different problem. SQL queries tables. FeatureQL defines, composes, and reuses business logic.
A feature is a single named calculation: "customer lifetime value", "eligible for discount", "days since last order". Features reference other features, and the system resolves dependencies, data fetching, and execution for you. You think in business concepts instead of tables and joins.
If you read SQL, the expressions will look familiar. What's new is the structural layer for composing features and navigating nested data.
What makes it 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, a finer granularity than SQL views, dbt models, or semantic-layer metrics.
Safety through types. The type system tells a customer ID from an order ID at compile time, so the compiler rejects joins between unrelated entities before they run. A static analyzer catches modeling mistakes at author time, fan-outs most importantly.
Same answer, verified. We adapt the transpiled SQL per backend so results align across engines, and back it with 4,000+ conformance tests you can run yourself against your own backends. Coverage grows continuously.
One definition, two paths. The same feature transpiles to SQL for batch and compiles to a prepared statement on DataFusion for serving. No reimplementation, no drift.
What it enables
Consistent logic everywhere. One definition of "active customer" or "MRR", enforced by the registry rather than a wiki page. A change that would break a downstream feature is caught before it ships.
Deep composition, debuggable by design. Build features on features. Because they transpile to flat CTEs in dependency order, you can inspect any intermediate step and walk the chain to the one that's wrong.
Experimentation without duplication. VARIANT() swaps one dependency in any feature and leaves the original untouched. Compare, roll out gradually, revert by removing the variant.
Faster onboarding. Analysts compose published features without relearning the schema each time. (Authoring the foundational source-mapping layer is a deeper skill, since everything builds on it.)
A safer surface for AI. Named, typed features give an LLM a smaller, safer search space than raw SQL. The model composes; humans validate intent, not syntax; the types and analyzer catch the mechanical errors. Every AI-authored feature lands as an inspectable, versioned artifact.
How it fits your stack
FeatureMesh sits alongside your warehouse and SQL, it doesn't replace them. Connect through a transparent proxy or embed FeatureQL inside regular SQL. Backends stay the same, adoption is gradual, and features transpile to standard SQL you can read and extract.
You might not need it
If you're one or two people doing your own analytics, your SQL files are fine. FeatureMesh pays off when the pain is already real: several people building on each other's work, logic that has to stay in sync across analytics and serving, and pressure to ship fast without breaking things.