Mahesh Murag describes Tecton's feature platform as a bridge between data science iteration and the reliability requirements of production engineering.
2
Jose Navarro explains how Cleo uses Feast with S3, Redis, Airflow, Kafka, and Spark to move feature computation out of request-time services.
3
Nikhil Garg breaks a feature platform into seven parts and argues that building one in-house takes much more time and engineering work than teams expect.
Summary
This session covers three approaches to building feature platforms. Mahesh Murag explains Tecton's unified interface for defining, computing, and retrieving features in Python, with offline point-in-time retrieval and low-latency online serving. He presents Rift as Tecton's Python-native compute engine and describes how the platform connects data scientists' need for fast experimentation with software engineers' need for versioning, monitoring, and reliable production systems. Jose Navarro shows how Cleo built a Feast-based platform with separate development and production deployments, S3 for offline storage, Redis for online retrieval, and Airflow, Kafka, and Spark for computation. The system moved expensive feature calculations out of request-time APIs and enabled new balance-related use cases. Nikhil Garg then decomposes a feature platform into authoring, compilation, metadata, computation, connectors, indexing, and catalog components. He is direct about the cost of building these parts, saying Fennel needed 15 months and six engineers to reach its desired milestone.
A feature platform connects raw data, features, and models across training and inference
Mahesh Murag defines a feature platform as the layer between raw batch, streaming, and request-time data; transformed features; and the models that consume them. It supports both training with point-in-time accurate historical data and inference with fresh production data. The platform also connects offline work, where data science and machine learning teams experiment, with online production applications. Feature definitions are reproducible, written as code, and visible to other team members. This gives teams one place to move from an experiment to a production feature without rebuilding the transformation separately.
Feature platforms have to satisfy data scientists and production engineers at the same time
Mahesh describes two groups with different expectations. Data scientists want fast iteration in notebooks, Python dependencies such as pandas and NumPy, access to data in different environments, and improvements in model quality. Software and platform engineers need versioned code, CI/CD practices, reproducibility, monitoring, uptime, and predictable retrieval latency. Historically, these jobs were separated, which made it difficult for organizations to move models into real-time applications. Mahesh presents the feature platform as the bridge between rapid experimentation and the operational work required to keep features available.
Tecton makes feature definitions portable from notebooks to production
Tecton lets users define transformations and aggregations declaratively in Python, then validate and publish them through a Tecton apply workflow. Mahesh says the same interface can be used in a notebook and in a feature repository, so a data scientist can copy the code into a Python file when it is ready for production. The platform handles orchestration, materialization, serving, and integration with version control. Users can also reuse feature definitions through workspaces instead of rebuilding the same work for different teams.
Rift is Tecton's Python-native answer to the trade-off between simplicity and scale
Mahesh introduces Rift as a managed compute engine for developing and productionizing batch, streaming, and real-time features with Python. It can execute queries locally in a notebook for offline retrieval, then use the same definitions in production. He contrasts this with Spark-based workflows, which can meet large-scale performance needs but often expose data scientists to difficult dependencies and error traces. Rift is intended to preserve Python-level iteration while supporting high-throughput aggregation, low-latency serving, caching, monitoring, alerting, and streaming ingestion.
Cleo moved feature calculations out of request-time services with Feast
Jose Navarro explains that Cleo previously calculated many features inside an API request, including information about a user's transactions. That increased latency, duplicated transformations between serving and training code, reduced reuse, and put load on the main database. Cleo chose Feast because its modular design allowed the team to build the platform incrementally. Feature definitions live in a Git repository, and GitHub Actions runs Feast plan and apply for separate development and production deployments. The resulting system supports shared feature definitions and online retrieval with single-digit millisecond latency.
Cleo combines different storage and processing systems for different feature needs
Cleo uses Amazon S3 as its offline store and Redis as its online store. Jose explains that Redis met the latency requirements while allowing less frequently accessed data to move to SSD storage. Airflow jobs read from the data warehouse and write results to the offline store before materialization into the online store. Kafka and Spark handle streaming features. Some features are calculated daily or hourly, while others are updated when new events arrive. This arrangement lets the platform match processing frequency to the importance and freshness requirements of each feature.
Nikhil Garg separates a feature platform from a feature store. A feature store mainly handles storage and serving, while a feature platform also covers authoring, data integration, computation, testing, and monitoring. His seven components are an authoring layer, a compiler, a metadata database, a compute engine, data connectors, an indexing layer, and a catalog. The authoring layer expresses feature computation. The compiler turns those definitions into jobs and other assets. The compute engine processes data, the index stores materialized values, and the catalog lets users discover features and inspect their status.
Building a feature platform involves difficult systems problems that are easy to underestimate
Nikhil points to point-in-time computation, stateful aggregations, snapshots, out-of-order data, exactly-once processing, backfills, large data volumes, and change-data-capture decisions. Streaming makes these problems harder, but batch systems also need careful handling of historical data. The indexing layer must deal with backup, replication, sharding, continuous windows, and network costs. A usable catalog also needs lineage, monitoring, alerting, access control, data quality checks, autoscaling, and unit testing. Nikhil says Fennel expected to reach its target in three months with four engineers, but it took 15 months and six engineers.
"A feature platform helps Bridge all of these things together into one place where every feature is reproducible, it's written as code and it's visible by any team member that's part of your organization."Mahesh Murag04:00
Who should watch
You are deciding whether a feature store is enough or whether your team needs a broader platform for authoring, computation, serving, and monitoring.
Your model service calculates features during requests and you need to reduce latency, database load, or duplicated training and serving logic.
You are considering building feature infrastructure in-house and want a practical account of the components, trade-offs, and engineering effort involved.
