Business use cases
FeatureMesh unifies data consumption in one system: a semantic layer for your data warehouse and a feature platform for your production APIs and real-time ML inference. It's designed for progressive adoption alongside your existing systems — no disruptive migration required.
Here's what that looks like in practice for different teams.
For data science & analytics teams
Build, test, and deploy models and insights faster — with more confidence and less repetitive work.
| Use case | The problem today | With FeatureMesh |
|---|---|---|
| Machine Learning | Feature engineering is cumbersome and error-prone. Training features and serving features drift apart silently. | Define features once. Use them identically in offline training (BigQuery, Trino) and real-time inference (DataFusion). Zero training/serving skew by construction. |
| Smart Decisioning | Data scientists depend on engineering to deploy pricing, promotion, or recommendation logic. Cycles are long. | Deploy decision logic as features directly. Test with VARIANT(), roll out with GRADUAL_ROLLOUT(), iterate without backend changes. |
| Experimentation | A/B testing tools are rigid, don't integrate with production data, and make sophisticated analysis difficult. | Run experiments with HASH01() for deterministic assignment and FeatureQL for custom analysis logic — all integrated with your actual data. |
| Simulations | Testing new models or business rules in production is slow, risky, and can impact customers. | Build digital twins with SAMPLE_UNIFORM(), SAMPLE_GAUSSIAN(), and SAMPLE_VALUE(). Validate changes before they go live. |
| Unified Analytics | Conflicting dashboards erode trust. Teams waste hours debating whose numbers are correct. | One source of truth for all metrics. Define KPIs once — every dashboard, report, and model uses the same logic. |
| Analytics with LLMs | Getting LLMs to generate correct SQL for complex business questions is unreliable due to convoluted schemas and joins. | LLMs write FeatureQL instead. They compose high-level, business-friendly features to answer questions that would fail with raw SQL. |
For engineering & platform teams
Build a more maintainable architecture while reducing boilerplate and technical debt.
| Use case | The problem today | With FeatureMesh |
|---|---|---|
| Feature as a Service | Building microservices just to access and transform data drains development and operational resources. | Deploy any feature as a performant API endpoint. One PREPARED_STATEMENT() turns a feature into a production-ready service — no infrastructure to manage. |
| Centralized Rules Engine | Business logic gets buried in backend code, invisible to non-engineers and slow to change. | Decouple business logic from application code. Rules are visible, editable by business teams, and updatable without backend deployments. |
| Highly Customized Products | Client-specific logic leads to a maze of if/else statements and a brittle codebase. | Isolate customer-specific configurations as feature VARIANT()s. Onboard enterprise clients without touching core code. |
For business & compliance teams
Gain visibility, control, and agility over the business logic that drives revenue and manages risk.
| Use case | The problem today | With FeatureMesh |
|---|---|---|
| Regulated Industries | Compliance teams need to verify business-critical logic (lending, insurance, healthcare) but can't read complex code. | FeatureQL's readable syntax lets compliance and legal teams verify rules against regulatory standards independently. Full audit trail included. |
| Business owns business logic | Business owners depend on long engineering cycles to update logic they're responsible for (promotion eligibility, risk thresholds). | Business teams own and iterate on decision logic themselves. FeatureMesh provides visibility and guardrails for confident changes. |
A concrete example
To make this tangible: here's what a "customer lifetime value" feature looks like in FeatureQL versus the traditional approach.
Traditional approach — A dbt model with CTEs joining customers, orders, and payments. An analyst copies and adapts it for a dashboard. An engineer rewrites it in Python for the API. Three implementations, three places to update when the logic changes.
FeatureQL approach:
-- Define once
CUSTOMER_LTV := CUSTOMER_ID.RELATED(
SUM(TABLES.FCT_ORDERS[amount])
GROUP BY TABLES.FCT_ORDERS[order_customer_id]
),
-- Use in a dashboard query
SELECT CUSTOMER_ID, CUSTOMER_LTV
FROM fm.analytics
FOR CUSTOMER_ID := @BIND_KEYSET();
-- Use in a real-time API (same feature, different execution)
PREPARED_STATEMENT(CUSTOMER_LTV);One definition. Used in batch analytics, real-time serving, and ML training. Updated in one place when the logic changes.