Feature Stores Without a Platform Team: A Pragmatic Blueprint

A feature store exists because ML models fail in two predictable ways:

1. Training/serving skew. At training you compute 'orders in last 30 days' via SQL. At serving, the app calls a Python function. Two implementations, subtle differences, model in production performs worse than in the notebook.
2. Feature duplication. Team A builds a 'customer LTV' feature. Team B builds a slightly different one. Team C builds a third. Now there are three definitions of the same thing.

Everything a feature store does is in service of these two problems. You can solve both with tools you already have.

Every batch feature is a dbt model. One SQL definition, one source of truth, materialized to your warehouse for training, exported to the online store for serving:

-- models/features/customer_features.sql
select
  customer_id,
  count(*) filter (where order_date > current_date - 30) as orders_30d,
  sum(total_cents) filter (where order_date > current_date - 90) as gmv_90d,
  max(order_date) as last_order_at,
  current_timestamp as computed_at
from {{ ref('stg_orders') }}
group by 1

This model is your feature contract. Any team using orders_30d reads it from this table. Change the definition, everyone sees it. Version via dbt's -- @deprecated comment or renaming.

For serving latencies of 10-50ms and QPS below a few thousand, a Postgres table with a simple sync job is enough:

create table online_customer_features (
  customer_id  uuid primary key,
  orders_30d   int,
  gmv_90d      bigint,
  last_order_at timestamptz,
  computed_at   timestamptz
);

-- nightly sync from warehouse
insert into online_customer_features
select * from warehouse.customer_features
on conflict (customer_id) do update set
  orders_30d = excluded.orders_30d,
  gmv_90d = excluded.gmv_90d,
  last_order_at = excluded.last_order_at,
  computed_at = excluded.computed_at
where excluded.computed_at > online_customer_features.computed_at;

When p99 lookup latency needs to be <5ms, add Redis as a read-through cache in front. Do not start with Redis — you'll spend weeks on cache invalidation for a problem you don't yet have.

Ship a tiny Python package that every model consumes. It hides the storage and enforces the registry:

class FeatureClient:
    def get(self, entity: str, entity_id: str, features: list[str]) -> dict:
        table = REGISTRY[entity].table
        cols = ','.join(features)
        return db.fetch_one(f'select {cols} from {table} where {entity}_id = %s', entity_id)

REGISTRY = {
    'customer': FeatureSet('online_customer_features', ['orders_30d', 'gmv_90d', 'last_order_at']),
    'product':  FeatureSet('online_product_features', ['view_count_7d', 'purchase_count_7d']),
}

Any code that asks for a feature not in the registry raises. Any dbt model that produces a feature registers it via a macro. Two-way enforcement, zero platform team.

Training reads from the warehouse table. Serving reads from the online table populated by exporting the same warehouse table. There is one implementation of every feature — the dbt model — and it runs once per day. Skew becomes structurally impossible for batch features.

For real-time features (last click, current cart) you still need to be careful — a separate section. But for the 90% that are 'aggregate over the last N days', this pattern eliminates the class of bug entirely.

• You have 3+ teams sharing features and the ad-hoc registry becomes a coordination bottleneck.
• You need point-in-time correctness for training — 'give me the value each feature had at the moment of each historical prediction' is genuinely hard to do in dbt alone.
• You need streaming features (last 60 seconds of activity) with sub-second freshness.
• You need feature lineage, monitoring, and drift detection out of the box.

Feast is the cheapest step up — open source, works with Postgres/Redis, no cloud lock-in. Tecton and Vertex Feature Store are managed but expensive; only adopt when the head count you save exceeds the license cost, which is usually at a 20+ ML engineer scale.