Feature infrastructure keeps the data supply chain operational from historical training data through production serving.
2
Companies often reach a second stage where separate feature systems, scaling needs, and new latency requirements make internal maintenance expensive.
3
For LLM applications, feature infrastructure can enrich prompts with relevant business and user context, while also supporting offline evaluation of prompts and signals.
Summary
Mike Del Balso traces feature platforms back to the production ML systems he saw at Google and helped build at Uber's Michelangelo. Large-scale models depended on reliable data pipelines that computed, stored, and served signals for both training and inference. He argues that teams need this infrastructure when models must run in production, especially when features are reused across teams or when systems move from batch predictions toward near-real-time and low-latency decisions. He describes the progression from a basic feature store to a broader platform with lineage, monitoring, integrations, and cost controls. Josh Wills asks where dedicated storage and query engines fit, including an Apache Iceberg-oriented future. Mike says Tecton plans a specialized serving layer while moving offline data toward more open interaction patterns. They also discuss LLMs, where features can provide prompt context and support offline evaluation. Josh questions whether dedicated vector databases will remain necessary for most workloads.
Production ML depends on an operational data supply chain
Mike says Google's ad models were trained and updated continuously, with thousands of features computed from many data sources. The hard part was not only the model. The system had to keep producing fresh signals, build training data, serve features in production, and manage feedback effects when a new model changed the predictions that later became training data. His lesson from Google was that high-quality AI systems depended on high-quality datasets and infrastructure for accessing, testing, and maintaining them.
A feature store makes prototype data work reproducible in production
At Uber, Mike helped build Michelangelo from a starting point with little ML infrastructure. The feature infrastructure let data scientists turn business data into reusable features, generate historical training datasets, and serve those features during inference. This addressed the gap between downloading data into a notebook and building a production system that keeps operating after the original prototype work is forgotten. Mike says the production finish line is a model or decision system delivering value to customers or the product.
The basic feature-store problem grows along several independent dimensions
Mike separates the initial task of productionizing a model from the later need to repeat that work across many teams. A basic system connects to data, computes features, stores them, and retrieves them for training or inference. Larger organizations then add requirements such as shared features, lineage, monitoring, streaming inputs, inference-time data, low latency, high scale, and cost control. These requirements do not arrive in one fixed order, so companies can have very different versions of an advanced feature platform.
Internal feature systems often become a costly patchwork
Mike describes how separate business units build systems for their immediate needs. One team may create a real-time Python service for fraud, while another later reuses it for personalization even though it was never designed as a shared system. Over time, a company can have separate infrastructure for streams, real-time features, Snowflake data, and a data lake. These pieces may all work individually while making training-data generation and production serving harder as a whole. Mike says this is why the build-versus-buy decision has shifted.
Batch and real-time workloads need a path between them
Mike describes operational ML as a production process that continues to run when its owner is unavailable. Workloads range from annual or daily batch predictions, through asynchronous processes that take minutes or hours, to near-real-time predictions based on recent history, and finally decisions that must complete in less than 50 milliseconds. A system built only for one point on this spectrum can make future upgrades expensive. Mike argues that a shared platform should support current needs while allowing teams to move toward faster decisions.
Feature platforms can provide context to LLM applications
Mike frames a feature system as a way to provide a model with relevant context about the world. For an LLM, that context can become part of a prompt rather than a structured feature vector. A support application might include the current ticket, earlier tickets, recent ticket volume, signup timing, and the user's common product activity. He says the same data pipelines used for traditional ML can prepare this information. The platform can also support offline exploration and evaluation by comparing prompts or signal sets against historical examples.
Vector retrieval and feature enrichment can work together
Josh questions whether most teams need a dedicated vector database when systems such as PostgreSQL with pgvector or search engines can support similarity retrieval. Mike expects many ordinary use cases to work with existing databases, while specialized systems may be justified by demanding latency or scale requirements. He describes a combined workflow in which vector retrieval generates candidate objects, then feature infrastructure adds many signals for each candidate before a model scores and ranks them. Josh connects this pattern to recommendation work at Slack.
Feature templates are attractive, but the right abstraction is unsettled
Demetrios asks whether common fraud features, third-party features, or complete application patterns could be templatized. Mike says the idea is appealing, but customer data and feature definitions rarely support simple copy-and-paste deployment. He thinks writing features is easier than adapting them to each company's systems and requirements. Mike believes the abstractions for feature infrastructure have become solid, while the right patterns for newer workflows around LLMs and related applications are still being worked out.
"We think about it as like we can help the context that you pass into the model, so the prompt, be highly enriched with relevant information about your business, the product, the user, the specific transactions, stuff like that."Mike Del Balso58:48
Who should watch
You are deciding whether a feature store is needed beyond notebook-based model development and want a practical description of the point where production requirements change.
Your platform team has separate systems for batch, streaming, online serving, or different business units, and you want to understand how that fragmentation develops.
You are building an LLM application and want to connect prompt context, retrieval, feature enrichment, and offline evaluation without treating them as unrelated workflows.
