Batch analytics
By defining features on top of analytics tables (BigQuery, Trino, DuckDB...), FeatureMesh becomes a semantic layer for your data warehouse.
What you get automatically
Single source of truth: Define "customer_lifetime_value" once in FeatureQL. Every dashboard, report, and analysis uses the same calculation.
SQL interoperability: FeatureQL compiles to native SQL for your warehouse. Your existing BI tools, notebooks, and dbt models work seamlessly.
Reusable business logic: Complex metrics become composable features.
ML feature engineering: Use the same features for training data generation and model evaluation. No more copying logic between notebooks and production code.
How it works
Your data team (or you yourself!) seeds the feature registry with the features sources you need.
CREATE FEATURES AS
CUSTOMERS := ENTITY(),
CUSTOMER_ID := INPUT(BIGINT#CUSTOMERS),
CURRENT_DATE := INPUT(DATE),
CUSTOMER_HISTORY := EXTERNAL_SQL(
`SELECT customer_id, orders_details FROM analytics.customers_history WHERE customer_id=%CUSTOMER_ID`
AS ROW(customer_id BIGINT#CUSTOMERS, orders_details ARRAY(ROW(order_id BIGINT, amount DECIMAL, order_date DATE)))
),
ORDERS_DETAILS := CUSTOMER_HISTORY[orders_details]
; You can then define autonomously the features you need:
CREATE FEATURES AS
LIFETIME_VALUE := ARRAY_SUM(ORDERS_DETAILS[amount]),
DAYS_SINCE_LAST_ORDER := DATE_DIFF(CURRENT_DATE, ARRAY_MAX(ORDERS_DETAILS[order_date]), 'day'),
ACTIVE_CUSTOMER := (DAYS_SINCE_LAST_ORDER <= 90) AND (LIFETIME_VALUE >= 100),
CUSTOMER_SEGMENT := CASE
WHEN LIFETIME_VALUE > 10000 AND ACTIVE_CUSTOMER THEN 'VIP'
WHEN LIFETIME_VALUE > 1000 AND ACTIVE_CUSTOMER THEN 'Premium'
ELSE 'Standard'
END
; And now anybody can query the features you defined from anywhere (Python, SQL clients, BI tools) on the set of customers they care about:
SELECT
CUSTOMER_ID := BIND_SQL(`SELECT id FROM customers WHERE country = 'US'`),
LIFETIME_VALUE,
CUSTOMER_SEGMENT
WHERE LIFETIME_VALUE > 1000 FeatureQL transpiles to optimized SQL that runs natively on your warehouse. No data movement, no new infrastructure.
Better than traditional semantic layers
Registry based, not YAML files: Traditional semantic layers use YAML configurations that require git workflows and deployments. FeatureMesh uses FeatureQL queries to add features to the registry with granular permissions. Queries fail if new features break consistency, guaranteeing a valid feature DAG at all times.
Full query flexibility: Tools like LookML provide safety through predefined metrics but lock you into their query syntax. FeatureMesh gives you the full power of SQL locally while maintaining consistent definitions.
Gradual adoption: Most semantic layers require modeling your entire schema upfront and querying through their interface. FeatureMesh works alongside your existing SQL. Start with one metric, add more over time. And mix SQL and FeatureQL queries as needed.