Tecton, Feast, Hopsworks. There is a whole product category called "feature stores," and it is well-funded, well-marketed, and well-represented in every ML platform talk of the last five years.

Most teams do not need one.

They need to be more disciplined with Postgres.

I want to be careful here, because feature stores solve a genuinely real problem. This is not a "you probably do not need Kafka" post. The train/serve skew problem is legitimate. Feature reuse is legitimate. Freshness SLAs are legitimate. What is oversold is the assumption that solving those problems requires adopting a dedicated product category. For teams below a certain scale, a well-designed Postgres schema is functionally equivalent - and the "well-designed" part is where the actual work lives, in either architecture.

What feature stores actually solve

Three things, roughly in order of importance.

First, train/serve skew. A model trained on a feature computed one way (say, a nightly job that aggregates ninety days of transactions in the warehouse) and served with a feature computed a different way (a Python function in the API path that pulls ninety days of transactions and aggregates them slightly differently) produces subtly different predictions in production than in training. This is the headline problem. Feature stores solve it by having one canonical definition of the feature that both training pipelines and serving APIs read from.

Second, feature reuse across models. If team A builds a "customer_recency_days" feature for a churn model, team B should be able to reuse it for an upsell model without re-implementing it, and without discovering three months later that A and B computed it differently.

Third, freshness SLAs. A feature that is 24 hours stale for a batch model is fine. The same feature for a real-time recommendation model is not. Feature stores make freshness an explicit contract, not an implicit assumption.

Those are legitimate problems. The question is whether solving them requires Tecton.

The Postgres-native equivalent

For a team with one ML system and a handful of models, here is the schema that does the same job.

Typed feature tables. One table per feature group, keyed on the entity you are predicting against - (organization_id, profile_id) for customer-level features, (product_id, day) for product-day features. Columns are strongly typed. Nullable columns have a documented meaning ("null means no transactions in the window," not "null means unknown"). Every feature table has a check on the null semantics; every feature has a test that fails if the semantics drift.

Materialized views or scheduled refresh jobs. Aggregations that would be too expensive to compute at query time run on a schedule. The refresh cadence is explicit and monitored, not a cron job that nobody has looked at in six months. Freshness is an SLO with an alert attached, not a hope.

Alembic migration history as feature lineage. Every change to a feature table is a migration. Every migration has a commit, an author, a date, and (if you write them like this) a description of what changed and why. That is your feature lineage. Not a separate UI. Not a separate metadata service. Just the migrations directory that your database already has, plus the discipline to write migrations that read like intent, not diffs.

A serving-time function that reads the feature row for the entity by primary key. If the training data was built by joining these same tables at a point in time, and the serving path reads from the same tables, the skew problem is solved by construction. Not by a service contract. By the fact that there is only one place the feature lives.

This is not clever. It is boring. That is a feature, not a bug. Boring architectures survive team turnover. Clever ones get rewritten.

When feature stores genuinely matter

Three scenarios where a dedicated feature store earns its keep.

Real-time streaming features. If your model needs to know a user's activity in the last thirty seconds, computed from a Kafka stream, joined with batch features from your warehouse, and served in under 50ms - a purpose-built store is doing work Postgres is not designed to do. This is not "Postgres cannot do it." This is "the code you would write to make Postgres do it is a feature store you built badly."

Point-in-time historical lookups for training. Time-travel joins - "what was this customer's feature vector on the day of the event, using only data available at that moment" - are a specific engineering problem. You can solve it in Postgres with careful table design (event tables with valid_from/valid_to columns, or ledger-style append-only feature history). It is possible. It is not free. If you are training many models against long historical windows, dedicated tooling starts to pay for itself.

Very large feature catalogs. Fifty models, three hundred features, twenty engineers who need to discover what exists. At that scale the catalog problem is real, and a UI helps. A team of five engineers with twelve features does not have this problem, no matter how much the vendor's landing page insists otherwise.

The build, buy, or defer decision tree

Three questions, in this order.

Do you have a real train/serve skew problem, right now, that is measurably degrading production model quality? If no, defer.

Do you need sub-second streaming features, or point-in-time historical joins at training scale? If yes, buy. If no, defer.

Do you have more than one ML team, or more than fifty features in active production? If yes, evaluate build versus buy on its merits. If no, defer.

"Defer" is the answer for the majority of teams that ask themselves this question. Deferring does not mean ignoring the underlying discipline. It means building the discipline into your database, with real migrations, real tests, real schemas, and a serving path that reads from the same tables the training path reads from.

Receipts

At Billity AI, the customer intelligence layer computes RFM features (recency, frequency, monetary) nightly in PostgreSQL. Aggregations run as scheduled jobs against transaction tables. Results land in a typed customer_rfm_features table keyed on (organization_id, profile_id). Behavioral embeddings live in an adjacent table using pgvector, keyed on the same composite. Serving reads from both by primary key. Training reads from the same tables bounded by valid_from. There is no dedicated feature store. There is no Tecton contract. Train/serve skew is zero, because the training rows and the serving rows are the same rows.

Will this architecture hold up when we cross five ML teams and a hundred features in active production? No. Is it the right architecture for shipping the first production model in a regulated environment where audit lineage matters more than platform elegance? Yes.

The counterpoint

The most common pushback: "Feature stores enable feature reuse across teams." True. In organizations with multiple ML teams sharing features, the coordination problem is real, and a shared catalog is one legitimate answer.

In startups with one ML team, the reuse problem is theoretical, not practical. There is no other team to reuse the feature. There is not going to be one for six quarters. Optimizing for that hypothetical is optimizing for the org chart you might have, not the one you do have. The engineering time that goes into standing up and maintaining a feature store in year one is engineering time that does not go into the model itself, the data pipeline that feeds it, or the evaluation harness that tells you whether the model is any good.

Close

Feature stores are great. Tecton is a real product solving a real problem for teams operating at real scale. The people who built Feast and Hopsworks are serious engineers, and I have no interest in dunking on their work.

The question is not whether feature stores are good. The question is whether you are at the scale where "great" beats "shipped six months ago."

For most teams reading this: not yet.

What is your team's rule for when a dedicated tool beats a disciplined schema?

Bryan Guy, J.D., is Founder and CEO of DataBillity, Inc. (dba Billity AI), building retrieval-first AI infrastructure for regulated industries.

#AIInfrastructure #MLOps #DataEngineering #Postgres #RegulatedIndustries #BillityAI

The "Feature Store" Is Just a Database With Good Manners