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. Each use case links to a tutorial with working code.
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. The same definition runs in offline training (BigQuery, Trino) and real-time inference (DataFusion), so skew can't come from a divergent reimplementation. Point-in-time correctness and source freshness are still yours to get right. |
| 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 published features rather than reasoning from raw schemas, which is a smaller and typed search space. |
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 an API endpoint. One PREPARED_STATEMENT() turns a feature into a served endpoint, with no service to write or deploy. |
| Centralized Rules Engine | Business logic gets buried in backend code, invisible to non-engineers and slow to change. | Rules live in the registry as named features, readable and reviewable outside the application codebase, and updatable without a backend deployment. |
| 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 it's scattered across code they can't review as a unit. | A rule is a named feature with explicit dependencies, reviewable as a unit rather than reconstructed from a codebase. Every version is registered and every execution reproducible, so "which rule produced this decision" has an answer. Reviewers still need someone to walk them through FeatureQL, but they're reviewing one named rule instead of a query. |
| Business owns business logic | Business owners depend on long engineering cycles to update logic they're responsible for (promotion eligibility, risk thresholds). | Thresholds and eligibility rules are isolated as named features rather than buried in code, so a change is a small reviewable diff instead of a backend ticket. Business owners can see and specify the rule; authoring still goes through someone who writes FeatureQL. |
Where this doesn't apply
These use cases assume shared business logic across several teams or systems. If one person owns the analytics and the logic, or the same calculation is never needed twice, the registry and the type system are overhead you don't need yet. Adopting a use case here is worth it when the same rule already exists in more than one place.