Define Once, Rewrite Anyway
A feature in machine learning is only defined once—until you demand it be correct.
Every serious feature store or feature platform solves the same embarrassment: models are trained on one view of the world, then served on another, and the mismatch is discovered only after going to production, when money is on the line or a company’s reputation is at stake. Most tools claim that we can define features once and let the platform deal with the training/serving skew by using a unified API that translates feature pipelines into equivalent batch and streaming workloads. The truth is that you still have to rewrite code, just not at the boundary between the batch and streaming worlds.
Tecton is very explicit about the promise and the constraint. The docs state that feature views enable “one feature definition for both training and serving”. Yet the same documentation distinguishes between batch and streaming: streaming “requires a different approach to aggregation and compute”, plus dedicated mechanisms for point-in-time data generation and backfills.
Chronon is more geared towards correctness. Airbnb describes it as an end-to-end feature platform. Its GitHub repo is even clearer: define features once and use the definitions for backfills and online serving. In Chronon’s case, backfills are point-in-time correct, because “consistency is guaranteed and measurable”. Chronon’s log-and-wait pattern exists precisely because it forces consistency from training through serving. That is also why Chronon can feel rigid during experimentation.
What these feature platforms do not say out loud is that “no rewrite” tends to mean “no rewrite within the platform’s boundaries”, and since exploration often happens outside such feature platforms in notebooks or one-off Python scripts with features that are “close enough”, there is at least one rewrite, at the most failure-prone moment in the lifecycle when moving from exploration to more serious development. This is also where the distinction between feature store and feature platform is relevant.
A feature store is a registry plus retrieval infrastructure: an offline path to reconstruct historical feature values for training and an online path to serve low-latency feature values for inference. Feast is the archetype. It offers point-in-time joins as a core capability to reproduce feature states at a specific time in the past. What a feature store typically does not do is own the entire transformation from sources. If upstream compute lives in separate batch jobs and stateful streaming applications, the store cannot force the two paths to be identical. It can make retrieval consistent, but it cannot guarantee what you retrieved was also produced by a single source of truth.
A feature platform adds computation and orchestration. Both Chronon and Tecton offer feature transformations, backfills, orchestration, serving, and observability. Stronger operational guarantees come at the cost of severe constraints on how features are computed. For instance, dynamic schemas, pivots, or embeddings are not supported. That is because real-time computation, point-in-time data generation, and backfills are much harder when the output schema is not known ahead of time. Teams either have to provide already flattened artefacts to the feature platform or transform certain features within the model code itself. Neither is satisfactory, as both options bypass the feature platform’s raison d’être.
None of these systems offers a middle ground between prototype and production. Most problems in machine learning arise from the glue code among the systems, not the modelling itself. These feature platforms behave as if there are two worlds: experimental chaos and pristine production. In reality, feature engineering and modelling are entangled. That is why “define once” really means “rewrite anyway”.