Chronon lets machine learning practitioners define computations over raw data while the platform generates the infrastructure needed for training and production serving.
2
Pre-aggregating metrics and generating retrieval embeddings requires batch pipelines, streaming systems, storage, serving, orchestration, and monitoring, which makes small prototypes difficult to productionize.
3
Chronon brings together infrastructure for different machine learning data tasks by making it easier to deploy and use existing open-source projects.
Summary
Nikhil introduces Chronon, an open-source data platform built at Airbnb and Stripe for machine learning and related data use cases. He explains why a simple chatbot feature, such as calculating a merchant's recent order-issue rate or retrieving similar issues, can require batch processing, streaming, storage, serving, orchestration, and monitoring. This infrastructure burden often means that data scientists use less context than their models could support, or wait months for engineering teams to turn prototypes into production systems. Chronon changes the workflow so users define computations over raw data, while the platform generates the infrastructure and exposes endpoints for training, evaluation, iteration, and application use. Nikhil says Chronon supported growth from about 3,000 to nearly 30,000 features at Airbnb and was used for ranking, fraud, customer support, marketing, rules, and metrics. He positions Chronon alongside existing tools rather than as a replacement for each one.
Chronon supports machine learning and non-machine-learning data use cases
Nikhil describes Chronon as a data platform built for machine learning at Airbnb and Stripe. At Airbnb, it is used for content and search ranking, account and payments fraud, customer support, and marketing technology. He also says the platform supports non-ML cases such as rule engines and metrics. This range matters because the same data computations can feed models, prompts, or ordinary application logic. Chronon was open sourced after being tested at Airbnb and Stripe, and Nikhil directs viewers to the project through a QR code and link.
Chronon helped Airbnb expand its feature use while reducing dependence on systems engineers
Nikhil says Airbnb grew from using about 3,000 features to nearly 30,000 in roughly three years. The number of models grew, and models also used more features. He attributes this to systems becoming faster to build, more scalable, and more performant out of the box. Previously, a data scientist could prototype in a few weeks or a month, then need a systems engineering team for many months or even a year to build the production ML system. Chronon aims to let practitioners work more independently.
A simple prompt metric can require a large production system
For an e-commerce chatbot handling a late order, Nikhil uses the percentage of a merchant's orders with issues during the last week as an example of useful context. Running a query over production order and issue tables may work initially, but scanning a merchant's full order history does not scale. The scalable approach pre-aggregates counts instead of reading raw orders on every request. That requires a batch pipeline over historical data, a streaming pipeline for recent data, a key-value store such as DynamoDB, and a service that supplies the result to the ML system or prompt.
Retrieval adds another set of pipelines and services
Nikhil's second example is finding issues similar to the current issue. The system must search issues across users, generate embeddings, store vectors, and retrieve the relevant results for the prompt. Embeddings may come from a deployed model or an external vendor such as OpenAI. The design also needs a vector store, a serving service, orchestration with Airflow, and monitoring with Grafana. More prompt elements, such as delivery-person issue rates or market-specific policy documents, multiply the infrastructure that must be built and operated.
Infrastructure complexity causes teams to use less data
Nikhil says the production burden has a direct effect on model and prompt quality. When each new data element requires its own pipelines, stores, services, orchestration, and monitoring, users often choose not to add enough data. The resulting context is weaker, so the model's responses are weaker. A notebook can be quick to read and build, but turning it into a production system is painful for one data scientist and remains a large undertaking even for a small systems engineering team.
Chronon turns user-defined computations into production endpoints
The central goal of Chronon is for ML systems to be generated rather than hand-built. Users define computations over raw data. Chronon generates the supporting infrastructure, which users then use to train and evaluate models and iterate on them. The platform also exposes production endpoints for applications. From the user's point of view, the workflow looks like writing Python code and reaching production endpoints without handing the system to an intermediate team that has to build everything manually.
Chronon connects existing tools instead of replacing every category
In the closing discussion, Nikhil divides the surrounding ecosystem into offline training-data generation, model training, feature serving, model serving, observability, and orchestration. He names Databricks and Snowflake for data pipelines, Tecton and Fennel for online feature serving, Vertex AI and SageMaker for model training and serving, and Arize and Fiddler for monitoring. Chronon's approach is to make it easier for organizations to deploy strong open-source projects in these areas and use them to generate the required infrastructure.
