Tecton Alternatives After the Databricks Acquisition

If Tecton sits under your fraud model or your personalization service, the August 2025 announcement raised a practical question. If you are on Databricks, the path probably runs through Databricks. If you are not, or you were about to buy Tecton, you need to know what else is out there and how each option is built.

Most comparison pages answer that with a feature checklist. That hides the more useful fact: almost every feature store is a coordinator. It defines features, schedules the jobs that compute them and copies the results into a key-value store for serving. The real differences sit in what it coordinates and what you have to run underneath.

This page walks through the main alternatives by how they’re built, then covers the option most lists leave out.

What Are the Alternatives to Tecton?

The main Tecton alternatives are Feast (open source), Databricks Feature Store, Google’s Agent Platform Feature Store (formerly Vertex AI Feature Store), Amazon SageMaker Feature Store, Hopsworks, Featureform (now part of Redis) and Chalk. Each pairs an offline store for training with an online store for serving. The other alternative is to compute features on demand in the system that already holds the state.

Before choosing one, it helps to be precise about what Tecton does today and what changed.

What the Databricks Acquisition Changes

On August 22, 2025, Databricks published “Tecton is Joining Databricks to Power Real-Time Data for Personalized AI Agents.” The post says “Tecton will soon be joining Databricks,” that Databricks had invested in Tecton and shares joint customers with it, and that customers “can expect deeper integration, with Tecton’s capabilities embedded directly into Databricks workflows and tooling.” It ties the deal to Agent Bricks, Databricks’ product for building AI agents.

It wasn’t Databricks’ first feature-engineering deal that year: in April 2025 it announced that Fennel joins Databricks, to integrate real-time feature engineering into its platform.

The announcement doesn’t set out a roadmap for Tecton as a standalone product. At the time of writing, tecton.ai redirects to databricks.com, while Tecton’s documentation site is still online. If you run Tecton outside Databricks, ask your account team directly about support terms and product direction, and plan from their written answer rather than from press coverage.

What Tecton Runs On

Tecton’s documentation describes the pieces a deployment connects:

Sources. Batch sources in a warehouse or data lake, and stream sources from Kafka or Kinesis (with Tecton on Databricks or EMR), or events pushed through Tecton’s Stream Ingest API, which is how streaming data reaches Rift.

Compute. Spark, or Rift, which Tecton calls its “managed compute engine.”

Online store. On AWS, DynamoDB by default, or Redis through ElastiCache or Redis Enterprise Cloud.

Offline store. Delta Lake or Parquet, for training data.

So a typical real-time Tecton deployment involves a stream, a warehouse or lake, a key-value store and Tecton coordinating them. Every alternative below has some version of that shape. The useful question is which pieces you run yourself and which are managed for you.

The Alternatives, by How They’re Built

Databricks Feature Store. Feature tables live in Unity Catalog. Databricks Online Feature Stores are powered by Lakebase, Databricks’ fully managed Postgres, and sync from the offline feature tables in one of three publish modes: triggered (the default, on a schedule or via API), continuous, or a one-time snapshot. The online value is as fresh as the last sync.

Feast. An open-source framework that registers features and serves them from an online store you choose. Its documentation lists backends including Redis, DynamoDB, Bigtable, PostgreSQL, Cassandra and others. The online store is populated by materialization from the offline store or by push sources. Feast’s own architecture overview notes that for streaming and batch sources it “requires a separate Feature Transformation Engine.”

Agent Platform Feature Store (Google Cloud, formerly Vertex AI Feature Store). Google now documents it under its Gemini Enterprise Agent Platform. It uses BigQuery tables or views as the offline store and data source, with Bigtable online serving or optimized online serving, and feature views that sync on a schedule or continuously.

Amazon SageMaker Feature Store. Feature groups can have an online store, an offline store or both. AWS’s documentation says the online store “retains only the latest records,” the offline store is append-only Parquet in your S3 bucket, and records arrive through a synchronous PutRecord API or batch jobs. Cross-group joins at inference time happen “in the client application.”

Hopsworks. An open-source platform where feature pipelines in Python, Spark or SQL write to versioned feature groups, and feature views group features for models, per its concepts guide. Online features are served from RonDB, an open-source distribution of MySQL NDB Cluster.

Featureform. A virtual feature store, built on Apache Iceberg, that orchestrates features on infrastructure you already run. Redis announced in October 2025 that Featureform is joining Redis and will be “incorporated into Redis’ feature store offerings,” with Redis as the online store and integrations with Spark, Snowflake, Iceberg and Kafka.

Chalk. Features are Python resolvers. Chalk’s documentation says it “computes and serves them directly from your data sources at inference time.” Per its caching docs, “by default, features are not cached, and instead are recomputed for every online request”; a max_staleness setting lets a cached value from the online store, such as Redis/Valkey or DynamoDB, be returned instead. Its offline store “is a data warehouse that stores all the features that you’ve computed.”

The common thread: in most of these, features are computed in one place, copied into a serving store and read from there. A served feature is as fresh as the last copy. Chalk inverts the default and computes at request time, so a feature is as fresh as the sources its resolvers read.

A Worked Example: One Fraud Feature

The timing below is illustrative.

Take a feature every card-fraud model uses: the number of transactions on this card in the last ten minutes. In a feature store stack it moves through four hops. The payment service writes the transaction to its database. An event goes to Kafka. A streaming job updates a windowed count. The count is written to the online store, where the model reads it.

Suppose those hops take three seconds end to end under normal load. A fraudster runs five card-testing transactions inside two seconds. Each fraud check reads a count that doesn’t include the others yet, sees one prior transaction, and approves. The stack did what it was built to do. The feature arrived after the decision needed it.

Now compute the same feature where the transaction is written:

SELECT count(*)              AS txn_count_10m,
       coalesce(sum(amount), 0) AS txn_amount_10m
FROM   card_transactions
WHERE  card_id = $1
  AND  created_at > now() - interval '10 minutes';

There is no pipeline, so the count includes every transaction committed before the query began (in PostgreSQL’s default READ COMMITTED level, a query sees all data committed before it started), including the four from a second ago. The trade is that the query runs at decision time, so the system holding the transactions has to answer an aggregate like this at the concurrency of the payment path while it keeps taking writes. That is exactly what a plain transactional database struggles with at scale, and why teams built feature stores in the first place.

How to Choose

If you’re on Databricks, Tecton’s capabilities are being folded into the platform you already run, and Databricks Feature Store keeps feature tables in Unity Catalog.

If you want open source and control over each component, Feast and Hopsworks are the two open-source options. Feast leaves compute and storage to you; Hopsworks brings its own platform and online store.

If you want features computed at request time in Python, Chalk’s default is to run resolvers per request and cache only where you allow staleness.

If you’re committed to one cloud, Google’s Agent Platform Feature Store and SageMaker Feature Store fit their ecosystems, with BigQuery and S3 as their offline stores.

If you already run Redis as your online store, Featureform is now Redis’s own orchestration option.

If your features are batch and daily staleness is fine, you may not need a feature store at all. This decision framework covers when one pays for itself, and how to evaluate a feature store covers the criteria.

If your features describe state that changes with every transaction and the decision can’t wait for a pipeline, the question shifts from which feature store to whether features should be copied at all.

Migrating Off Tecton: What to Inventory

Whichever option you pick, the migration has the same shape. Before comparing products in detail, list what your Tecton deployment actually does, because that list is the requirement.

Feature views, by type. Batch and stream feature views are materialized ahead of time. Realtime Feature Views run “row-level, request-time operations,” written as Python or Pandas transformations or as Calculation features. Request-time logic needs a home that runs at inference in the new stack, not just a table to copy.

Feature services. Tecton’s Feature Services “group features from Feature Views together for training and serving.” Each one is roughly a model’s contract: the feature list, the online endpoint and the training-data call. Map them one to one.

Training data. Tecton’s get_features_for_events() returns values that are “point-in-time correct, meaning no future data is inadvertently included” (docs). The replacement has to reproduce those point-in-time joins, or retrained models learn from data they won’t have at inference.

Freshness, per feature. Write down how fresh each feature is today and how fresh the decision needs it. Some will turn out to be batch features that never needed a stream.

Then shadow before you cut over. Run the new path alongside Tecton, request both for the same entity at the same moment, and compare values feature by feature. Cut traffic over model by model once they agree.

Compute Features Where the State Lives

This is the alternative most comparison pages skip. A feature store exists to bridge two systems: the one where state changes and the one fast enough to serve features. If one system could take the writes and serve the aggregates, windows and lookups behind features at decision-time concurrency, the bridge isn’t needed.

That changes how feature freshness works. Instead of every feature being as fresh as the shared pipeline, each feature picks its own mode: computed on demand when the decision depends on the latest write, or precomputed when it can lag. Training data comes from the same tables, so training and serving use one definition.

It isn’t free. You need a system that can take that load, and Java or Scala stream operators that go beyond SQL still need a stream processor. Pure batch features gain nothing from it.

Where Tacnode Fits

Tacnode is built for that last option. The Tacnode Context Lake™ is context infrastructure: one system where the data a decision depends on is written, derived and served under one consistent snapshot.

Features are SQL. Most run on demand against the latest committed data, like the query above. Expensive aggregates can be incremental materialized views, refreshed incrementally on a schedule you set in SQL, typically every few seconds, where each refresh applies only what changed. Source data from the systems you already run can arrive by change data capture, and decisions the model makes, such as scores and holds, can be written back to Tacnode as context for the next decision. Tables export to Iceberg, so training pipelines and the warehouse can read them in place.

Tacnode isn’t a feature store, and it doesn’t train or serve models. It holds the derived context models read, in the same place the state changes, so there is no separate serving copy to keep in sync. Live context covers how freshness is set per feature.

FAQ