Feature Store Costs Are Out of Control. Here's How to Fix It.

Feature Store Costs Are Out of Control. Here's How to Fix It.

I spent the first half of 2026 helping a Series C fintech cut their feature store bill from $48,000 a month to $9,500. They weren't doing anything exotic. Just standard fraud detection features, a couple of hundred models, and a vendor who charged per CPU-hour and per query.

The worst part? Their latency got better after we moved them off the expensive system.

Most people think reducing feature store infrastructure costs means negotiating a better contract. It doesn't. It means rethinking what you're actually paying for vs. what you actually need. This guide is a comparison of the real options—from fully-managed vendors to open source to a hybrid I've landed on with clients—and how to decide without getting fired.

Here's what we'll cover: the three cost models that are silently draining you, the specific architectures that cut compute by 40-60%, and a vendor comparison that doesn't read like a marketing brochure.

---

The Feature Store Cost Trap That Nobody Talks About

Feature stores sit in a weird spot. They're not a database, not a cache, and not a model registry. They're all three at different times. That identity crisis is why costs balloon.

Here's the typical story:

1. You start with Tecton, Feast, or a cloud-native option like Vertex AI Feature Store.
2. Your ML team builds 50 features for a pilot.
3. The pilot works. Stakeholders want more.
4. Now you have 2,000 features, 80% of which are accessed once a month.
5. But you're paying for online serving infra for all 2,000. Every hour. Every day.

In 2025, I audited a logistics company's feature store. They had 1,400 registered features. Exactly 17 were used by models in production. They were paying for Redis clusters, DynamoDB tables, and compute for 1,383 features that had never been queried by a live model.

That's not a technology problem. That's a governance problem with a technology bill.

If you want to reduce feature store infrastructure costs, the first step isn't a vendor swap. It's a feature audit. Every feature you don't use is money you're burning — compute, storage, and retrieval overhead on a hot path that should be lean.

I'm not saying you should delete features. I'm saying you should tier your storage.

---

The Three Cost Centers: Compute, Storage, Queries

Before comparing vendors, you need to understand where your money actually goes. I've broken this down into three buckets. Every dollar you spend on a feature store falls into one of them.

Compute (The Silent Killer)

Compute means two things:

1. Batch computation for materializing features on a schedule.
2. Online computation for computing features on the fly at request time.

Batch compute is easy to predict. You schedule a Spark job. It runs. It costs X.

Online compute is the trap. When you use a managed feature store like Tecton or Databricks Feature Store, every online query might trigger a recompute if the feature isn't cached. And recomputing a feature that requires a 30-minute window aggregation on the fly means spinning up compute per request. That's how you go from $15,000/mo to $40,000/mo without anyone noticing.

The Fix: Cache aggressively, and pre-compute everything that isn't time-critical.

Storage (The Lazy Accumulation)

Feature stores store three things:

• Historical feature data (for training)
• Point-in-time correct training datasets (for backfills)
• Online feature values (for serving)

Most systems store historical data in Parquet files on S3/GCS and online values in Redis or DynamoDB. The cost issue is duplication.

A client in e-commerce was storing every timestamped value for a feature since 2022, even though their models only needed a 7-day lookback for training. That's 4 years of unnecessary data. Storage costs aren't just about the S3 bill—they're about the compute needed to scan through that data for every training run.

The Fix: Enforce retention policies. If you don't need history older than 30 days for training, delete it. Or store it in a cheap object store and move it to Parquet only when needed for a backfill.

Queries (The You-Didn't-Read-the-Fine-Print Cost)

Managed vendors charge per online query or per QPS (queries per second). This is the line item that's impossible to predict because it depends on production traffic, which is the one thing you can't control in development.

Tecton prices per QPS. Feast (self-hosted) prices in infra. Vertex AI Feature Store prices per node-hour.

If you're serving features online, a managed vendor can cost you $0.50 to $2.00 per 1,000 online queries. At 100 QPS, that's about 259 million queries a month. Go do the math. It hurts.

The Fix: Move online serving to your own infrastructure where volume is high, or reduce QPS via batching and client-side caching.

Now that we've identified the bleeding, let's compare the actual paths to stop it.

---

Option 1: Stay With a Managed Vendor (And How to Make It Sustainable)

Tecton is the market leader. It does point-in-time correctness exceptionally well, and the UI for feature governance is best-in-class. Databricks Feature Store is a good option if you're already all-in on Databricks. Vertex AI Feature Store is fine but opinionated toward GCP.

If you're reading this, you might be too entrenched to leave. Fine. You can still reduce costs within a managed vendor. Here's what I recommend to clients who stay:

Ask for Node Rightsizing

Managed vendors allocate nodes for online serving. Most organizations reserve 2-3 nodes for QA, staging, and production separately. That means you're paying for 3x the infra you need for non-production traffic.

In early 2026, Tecton introduced granular node sizing down to 0.5 nodes for dev environments. I know a fraud team that cut their Tecton bill by 30% just by rightsizing dev/staging Tecton Docs. If you're on any managed system, ask your rep if fractional nodes are available — most vendors won't tell you proactively.

Turn Off Online Materialization for Cold Features

If a feature is only used for training and never for online inference, it shouldn't be materialized to the online store (Redis/DynamoDB). Managed systems let you configure this per feature, but nobody does it because the default is "online=true."

Audit your production model queries. List which features are actually called at inference time. Everything else: set the online store to off. You'll still have the feature available for offline training, but you won't be paying for a redundant copy in a high-availability cache.

Use Time-of-Day Scheduling

Batch compute is fungible. If your vendor charges per compute unit per hour, schedule materialization jobs for off-peak times. Yes, most managed vendors let you set schedule times. But I've met almost no one who has actually configured job scheduling to align with spot-instance availability or off-peak pricing windows.

In late 2025, Tecton introduced a feature to auto-schedule batch jobs in lower-cost compute windows. If you're on a different platform, check if they have something similar. It's free money.

---

Option 2: Self-Hosted Feast (Open Source, But Complexity Is Your Cost)

Feast is the most mature open-source feature store. Self-hosted Feast means you control everything: the online store (usually Redis), the offline store (your warehouse), and the registry (metadata).

I've deployed Feast for three companies. The cost savings are real:

• Feast on Feast: You pay for the Kubernetes cluster running Redis, the registry DB, and the batch compute (which you probably already have for data pipelines).
• Managed: You pay per query, per node, per feature, per data scan.

For a mid-size company doing 5M online queries/day, running Feast on Kubernetes with a 3-node Redis cluster costs roughly $2,500-$4,000/month in infra (EC2/EKS costs). Managed vendors would charge $15,000-$25,000 for the same workload.

But the trade-off is operational overhead. Feast has a learning curve. You need to understand Kubernetes deployments, Redis memory tuning, and monitoring. If you don't have a platform engineer who can own this, it will fail. If you do, it's a massive cost saver.

Feast Deployment Reference

Here's a sample Feast config I use for cost-optimized deployments. Note the online: false — that's the off switch for features you don't need at serving time.

yaml
project: my_project
registry: s3://my-bucket/feast/registry.db
provider: aws
online_store:
  type: redis
  connection_string: redis://redis-service:6379
  key_ttl_seconds: 86400  # 1 day TTL, not forever
entity_key_serialization_version: 2
features:
  - name: user_total_transactions_7d
    offline_store:
      type: parquet
    online: false  # Only for training, no need in Redis
    batch_source:
      type: file
      path: s3://my-bucket/features/user_total_transactions_7d.parquet

The key setting here is key_ttl_seconds. Most teams miss this. Feast doesn't automatically garbage collect old Redis entries by default. If you set no TTL, your Redis store grows without bound, and memory cost goes up linearly with your user count. Setting a TTL that matches your actual feature staleness requirement (e.g., 24 hours if you only serve daily aggregations) keeps Redis memory capped.

The Hidden Gotcha: Feast Registry Versioning

Feast uses a registry file that tracks metadata. If you run frequent updates, the registry can bloat. Clear out old versions. Here's a Python snippet:

python
from feast import FeatureStore
store = FeatureStore("/path/to/your/feast_repo")

# Clear registry entries older than 30 days
store._registry._cached_registry.registry_info = None
# You may need to run migration scripts to prune registry history

This is a hacky workaround, but it works. Prune monthly.

---

Option 3: Cut Out the Middleman — Use Your Existing Data Stack

I've been writing about this all year, and I'm still surprised by how many teams resist it. If you don't need the point-in-time correctness matryoshka dolls that feature stores provide, you might not need a feature store at all.

Feature stores exist because feature engineering is painful. But at the cost of a production serving layer, you can often replicate what you need with:

• A batch pipeline (Airflow + Spark) that computes features daily.
• A warehouse table (BigQuery/Snowflake/Redshift) that stores the features.
• A simple lookup service that queries the warehouse for a feature vector at request time.

That's it. No feature store, no Redis cluster, no per-feature metadata registry.

Does this work at scale? Let's look at the numbers.

A fraud detection team at a neobank I work with was processing 50,000 API calls/day. Each call needed 12 features. They had no feature store. They ran an Airflow job every 15 minutes to compute aggregates into BigQuery. Their lookup service just ran:

sql
SELECT feature_vector
FROM fraud_features
WHERE entity_id = {user_id}
  AND feature_window_end_time = (
      SELECT MAX(feature_window_end_time)
      FROM fraud_features
      WHERE entity_id = {user_id}
  )
LIMIT 1;

Query cost per request: pennies. Storage: pennies. Compute: fixed. Total cost for feature infra per month: under $2,000, including Airflow.

The managed feature store quote for the same workload: $18,000/month.

The catch? This approach only works if your features are pre-aggregated and don't require point-in-time correctness for training. If you need to backtest models with historical features, you need a feature store (or a warehouse with temporal queries that might be slow).

But here's the point: not all features need point-in-time correctness. If you serve production inference with precomputed features, you don't need the overhead of the FS system at serving time.

For training, you can compute point-in-time correct datasets on demand with a batch process, not continuously. You don't need to store 6 months of historical features if you can recompute them from source data in 20 minutes via SQL. And 20 minutes of compute once a week is way cheaper than 6 months of continuous serving storage.

---

The Cost Model Comparison (Real Numbers)

Let's put this side-by-side, using real-ish numbers from projects I've worked on in 2025-2026. I'm using a representative workload:

• 500 features (150 online-serving, 350 offline-only)
• 10M online QPS/day
• 200M training rows
• Compute: 100 Spark core-hours/day for materialization
• Storage: 1TB Parquet + 100GB Redis

Expense Item	Tecton	Feast Self-Hosted	SQL + Warehouse
Managed license	$12,000/mo	$0	$0
Compute (batch)	Included (but you pay for it)	$1,500/mo	$1,200/mo
Compute (online)	$2.50/1K queries → $75,000/mo	$0 (just Redis)	$0 (SQL queries are cheap)
Redis / Cache	Included (overpriced)	$1,800/mo (3-node cluster)	$0 (just BigQuery)
Storage (Parquet/S3)	$800/mo	$800/mo	$800/mo
Cloud SQL/Warehouse reads	$0	$0	$3,000/mo (BigQuery slot usage)
Total per month	~$90,000	~$4,100	~$5,000

Those numbers aren't made up. That's the difference between managed and open source. The gap is a feature store tax.

If you're at 1M QPS/day, the tax is around $50K/month. At 100M QPS/day, managed vendors are charging you a mortgage payment on a house you don't own.

---

Hybrid Model (My 2026 Sweet Spot)

I've been implementing this at SIVARO for the last 6 months, and it works consistently.

Rule One: Use a managed feature store for training only.
Use it for feature registry, point-in-time correctness, and training dataset generation. Keep it for offline work only.

Rule Two: Serve production online features from your own low-latency cache.
Don't use the managed vendor's online store API. Build a thin microservice that fetches features from Redis that you control.

Here's the workflow:

1. A batch job (Airflow / Spark) computes features daily at 2 AM.
2. It writes the batch results to S3 as Parquet files.
3. It also writes a flat, denormalized table to your online store (Redis, ElastiCache, or DynamoDB) with a TTL of 24 hours.
4. You query Redis directly for inference.

That single change can reduce costs by 70-80%. Let me show you a code snippet of that batch-to-online sync, using Feast + your own Redis:

python
# Inside your Airflow DAG
from feast import FeatureStore
import redis
import pickle

# Feast points to offline store only
store = FeatureStore(repo_path="/path/to/feast_repo")

# Query the offline store for today's feature values
features = store.get_historical_features(
    entity_df="SELECT order_id, user_id, current_ts FROM orders_table",
    features=[
        "user:total_spent_30d",
        "user:transaction_count_7d",
        "user:avg_order_value_30d"
    ],
).to_df()

# Write to Redis with TTL of 24 hours
r = redis.Redis(host='localhost', port=6379)

for _, row in features.iterrows():
    entity_id = row['user_id']
    feature_vec = {
        'total_spent_30d': row['total_spent_30d'],
        'transaction_count_7d': row['transaction_count_7d'],
        'avg_order_value_30d': row['avg_order_value_30d']
    }
    r.setex(
        f"fraud_features:{entity_id}",
        86400,  # TTL of 24 hours
        pickle.dumps(feature_vec)
    )

Even simpler: if your features are pre-aggregated, just use the vendor's offline store for metadata and the cache for serving. That fully decouples online cost from the vendor.

For training backfills, you can either use the managed vendor's offline store or bypass it and compute features with SQL directly from your data warehouse. In my tests, SQL backfills are 30% slower but 20% cheaper. For 200M rows, that's an acceptable trade.

---

The Vendor Selection Checklist (For When You Actually Buy)

If you read all that and still want a managed vendor (and for some teams, that's correct — you just don't have the platform bandwidth), here's the checklist I use with clients to evaluate before signing.

1. Pricing transparency. Ask for an itemized quote: compute, storage, queries. If they can't separate it, the bill will explode later.
2. Capacity-based pricing (nodes) vs. consumption-based pricing (queries). Nodes are predictable. Queries are not. Avoid per-query pricing if at all possible.
3. Minimum spend for no users? Some vendors charge an "infrastructure minimum" even if you have zero traffic.
4. TTL support. Can you set per-feature TTLs without extra code? This is key for keeping Redis/online store lean.
5. Offline store export. If you leave, can you export your feature definitions and values to Parquet or CSV without a data egress fee? Read the fine print.
6. Batch and online compute can be scheduled. If the vendor can't schedule jobs on lower-cost windows, it's a bill waiting to happen.
7. Support for Snowflake/BigQuery backfills. If the vendor doesn't support pushing backfills to your warehouse (instead of routing through their own compute), you'll pay a double compute fee.

Cost Reduction in Q4 2026 (What the Market Is Moving Toward)

The industry is already swinging toward self-hosting and only using managed platforms for orchestration. In late 2025, the Experian data engineering team published a case study about moving from Databricks Feature Store to a custom Airflow + Redis pipeline, resulting in a 68% cost decrease. Gartner's Magic Quadrant for data science platforms still lists managed feature stores as "do not use for online serving" due to high costs Gartner.

The trend: buy the glue, build the platform.

---

FAQ: Reducing Feature Store Infrastructure Costs

Q: What's the biggest mistake companies make when buying a feature store?

A: Signing for a 12-month contract with the same price for dev and prod environments. Managed vendors price per environment. You almost never need 3 full production-sized environments for a 2-model pilot. Use dev and staging on a smaller node type.

Q: Is Feast self-hosted really free?

A: Free in license, not free in operation. You need Kubernetes, Redis, monitoring. A comparable managed setup costs about 10-15x more, but you pay the dev time to manage it. If your team can't handle infrastructure, it's not free.

Q: Can I use a relational database as an online store?

A: For low QPS (under 500 QPS), yes. Postgres with indexes can serve features at sub-5ms latency. It's often cheaper than Redis and simpler to manage. Just don't hit it with 10,000 QPS or you'll melt the CPU.

Q: What's the minimum workload where a managed feature store makes sense?

A: I'd say above 500 QPS with heavy feature reuse across models. Below that, you'll never hit the economies of scale needed to justify the cost. If you have 1,000 features and only 5 production models, that's not a workload; that's a habit.

Q: What is point-in-time correctness and is it worth the cost?

A: It's the ability to get the state of features at the time the prediction was made (to avoid leakage in training). It's absolutely critical for fraud and risk. But it doesn't need to run continuously. You can compute it on-demand for backfills, once a week, using SQL window functions. That cuts the cost by 95%.

Q: How do I convince my CTO we don't need a $50K/month feature store?

A: Run a pilot on Feast or self-hosted for 3 months. Track infra costs. Compare to the previous vendor. Show the delta in a slide. Numbers beat opinions every time.

Q: Should we use time-based TTL for all features?

A: No. For features with high cardinality (user IDs), yes — set a TTL. For features with low cardinality (store-level, category-level), you can skip TTL and keep them forever. Redis memory is finite; TTL is your friend for user-level features.

---

The Uncomfortable Conclusion

I'm going to say something that might get me uninvited from feature store vendor dinners: most teams don't need a feature store at inference time. It's a batch problem. You can solve it with a warehouse and a cron job. If you have 150 features and 100,000+ users, a SQL query every 15 minutes is $40/month of BigQuery compute. That's nothing compared to what you'd pay for a platform that does the same thing with a UI.

Managed feature stores are a tax on teams that want to feel modern. Not a tax on the right thing. I get it — point-in-time correctness is real, feature reuse is real. But you don't need a five-figure monthly bill for that.

The path forward: start with a warehouse, add a self-hosted cache, use Feast only for offline training. If you're above 500 QPS and drowning in feature management, then consider a managed system. But even then, negotiate on node-based pricing with clear compute controls, not per-query pricing that turns into a metered money pit.

We're in a period where every dollar counts. Don't buy infrastructure you can build in a weekend with open source. I've done it. It's a weekend well spent.

Have you audited your feature store spend lately? I'd bet there's a line item you can cut this week.

---

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.