Tecton: Enterprise Feature Platform

Tecton Overview

Tecton was founded by the creators of Uber's Michelangelo ML platform—the same team that pioneered the open-source Feast project. While Feast provides a flexible, self-managed feature store, Tecton takes the concept further by offering a fully managed enterprise feature platform that abstracts away the infrastructure complexity of running production ML pipelines.

At its core, Tecton provides three key capabilities:

• Managed feature pipelines — batch, streaming, and real-time transforms executed on Tecton's infrastructure
• Unified feature serving — a single API for both online (low-latency) and offline (training) feature retrieval
• Feature monitoring & governance — built-in data quality checks, lineage tracking, and access controls

Tecton integrates natively with major cloud providers (AWS, GCP, Azure) and data platforms (Snowflake, Databricks, Spark), making it suitable for enterprises that want production-grade ML infrastructure without building it from scratch.

Tecton Architecture

Tecton's architecture is built around a declarative feature definition layer that sits on top of managed compute and storage infrastructure. Engineers define features as Python code, and Tecton handles scheduling, compute orchestration, and serving.

The architecture has four major layers:

1. Data Source Connectors — ingest from S3, Snowflake, Kafka, Kinesis, or direct HTTP requests
2. Managed Compute — Tecton orchestrates Spark, Rift (Tecton's native engine), or serverless compute to run transformations
3. Feature Repository — a Git-backed declarative store where feature definitions live as Python objects
4. Dual-Store Serving — DynamoDB/Redis for online serving, S3/data-warehouse for offline training retrieval

Feature Pipelines in Tecton

Tecton supports three types of feature pipelines, each defined declaratively using Python decorators. Feature definitions are stored in a Feature Repository—a Git-managed directory of Python files that Tecton parses and deploys.

Batch Feature Views

Batch features are computed on a schedule (e.g., daily or hourly) from warehouse data. These are the most common type and are ideal for features that don't need sub-second freshness.

# batch_features.py — Daily aggregation of user purchase behavior

from tecton import batch_feature_view, FilteredSource
from tecton.types import Float64, String
from datetime import timedelta

from data_sources import transactions_source

@batch_feature_view(
    sources=[FilteredSource(transactions_source)],
    entities=[user_entity],
    mode="spark_sql",
    online=True,
    offline=True,
    feature_start_time=datetime(2023, 1, 1),
    batch_schedule=timedelta(days=1),
    ttl=timedelta(days=30),
    description="User purchase statistics over trailing 30 days",
)
def user_purchase_stats(transactions):
    return f"""
        SELECT
            user_id,
            COUNT(*) AS purchase_count_30d,
            AVG(amount) AS avg_purchase_amount_30d,
            MAX(amount) AS max_purchase_amount_30d
        FROM {transactions}
        WHERE timestamp >= current_date - INTERVAL 30 DAY
        GROUP BY user_id
    """

Streaming Feature Views

Streaming features consume events from Kafka or Kinesis in near-real-time. Tecton manages the Spark Structured Streaming or Rift jobs behind the scenes.

# streaming_features.py — Real-time click aggregations

from tecton import stream_feature_view, Aggregation
from tecton.types import Float64, Int64
from datetime import timedelta

from data_sources import click_events_stream

@stream_feature_view(
    source=click_events_stream,
    entities=[user_entity],
    mode="spark_sql",
    online=True,
    offline=True,
    aggregation_interval=timedelta(minutes=5),
    aggregations=[
        Aggregation(column="click", function="count", time_window=timedelta(hours=1)),
        Aggregation(column="click", function="count", time_window=timedelta(hours=24)),
    ],
    description="User click counts over 1h and 24h windows",
)
def user_click_counts(click_events):
    return f"""
        SELECT user_id, 1 AS click, timestamp
        FROM {click_events}
    """

Real-Time Feature Computation

Some features can only be computed at request time because they depend on data available only during inference (e.g., the current request payload). Tecton supports this through On-Demand Feature Views.

# on_demand_features.py — Request-time feature computation

from tecton import on_demand_feature_view, RequestSource
from tecton.types import Float64, String, Field

request_schema = [
    Field("current_amount", Float64),
    Field("merchant_category", String),
]

@on_demand_feature_view(
    sources=[RequestSource(schema=request_schema), user_purchase_stats],
    mode="python",
    schema=[
        Field("amount_vs_avg_ratio", Float64),
        Field("is_high_value_txn", Float64),
    ],
    description="Compare current transaction against user history",
)
def transaction_context_features(request, user_purchase_stats):
    avg = user_purchase_stats["avg_purchase_amount_30d"] or 1.0
    ratio = request["current_amount"] / avg

    return {
        "amount_vs_avg_ratio": ratio,
        "is_high_value_txn": 1.0 if ratio > 3.0 else 0.0,
    }

On-demand features are computed server-side by Tecton's serving infrastructure, so they add minimal latency to your inference calls. They can also combine pre-computed features (from batch or streaming views) with request data for powerful contextual enrichment.

Fetching Features at Inference Time

# inference.py — Retrieve features for a prediction request

import tecton

ws = tecton.get_workspace("production")
feature_service = ws.get_feature_service("fraud_detection_service")

# Online retrieval with request-time context
response = feature_service.get_online_features(
    join_keys={"user_id": "usr_12345"},
    request_data={
        "current_amount": 499.99,
        "merchant_category": "electronics",
    },
)

features = response.to_dict()
prediction = model.predict(features)

Tecton vs Feast

Since Tecton was created by the original Feast team, the two share DNA but diverge significantly in scope and operational model. Here's a detailed comparison:

When to Choose Tecton

Tecton is best suited for organizations that are operationalizing ML at scale and need a platform that handles the full feature lifecycle. Consider Tecton when the following criteria apply:

Decision Criteria

1. Team composition: Your ML engineers want to focus on feature logic, not infrastructure plumbing. Tecton removes the need to manage Spark clusters, streaming jobs, and serving infrastructure.
2. Feature freshness: You require real-time or near-real-time features (streaming + on-demand). Self-managing streaming pipelines is one of the hardest parts of ML infrastructure.
3. Scale: You're serving features for hundreds of models across multiple teams. Tecton's feature registry and governance tooling becomes essential at this scale.
4. Compliance: You need audit trails, access controls, and data lineage for regulatory requirements (finance, healthcare).

Common Enterprise Use Cases

• Fraud detection — combining real-time transaction context with historical behavior patterns
• Recommendation systems — streaming user engagement signals merged with batch-computed item embeddings
• Dynamic pricing — real-time supply/demand features feeding pricing models
• Credit risk scoring — on-demand features from application data combined with pre-computed financial history

In the next posts, we'll explore the serving patterns (online vs offline) and pipeline architectures that platforms like Tecton implement under the hood, giving you a deeper understanding of what these tools do for you.