The Traditional SaaS Pricing Model for Observability Is Broken

SaaS observability platforms do not charge you once. They charge you per GB of logs ingested, per host monitored, per custom metric reported, per indexed span retained, and per user seat. Each pricing dimension scales independently. When your Kubernetes fleet grows, you pay more on the per-host axis. When you enable richer instrumentation, you pay more on the per-metric and per-span axes. When you onboard a new team, you pay more on the per-seat axis. The result is not a linear increase — it is a combinatorial one, and at today's telemetry volumes it produces bills that are genuinely unpredictable.

This is a structural problem, not a negotiation problem. Each pricing axis was added to capture a different slice of the value a customer derives from observability. Individually, each seems defensible. Collectively, at the scale of a modern infrastructure generating terabytes of telemetry per day, the sum of all dimensions compounds into costs that force engineering teams to observe less — not more — of their systems. You cannot discount your way out of a model where five independent meters are all running at once.

The fix is not cheaper pricing on any single dimension. It is an architectural change. The observability data lake model collapses multi-dimensional pricing into a single axis: storage cost per GB per month on commodity object storage. Compute for queries, alerts, and dashboards is a separate, transparent cost. When the dominant expense is object storage at $0.02/GB/month, the incentive misalignment disappears. Better instrumentation does not trigger a bigger bill across five axes — it just stores more Parquet files in your S3 bucket.

The Multi-Dimensional Pricing Trap

SaaS observability pricing is not a single meter. It is a stack of independent meters, each tied to a different dimension of your infrastructure:

• Per-GB ingestion — the base unit. Every log line, every trace span, every metric data point costs money when it enters the platform. This is the number on the pricing page, but it is only the beginning.
• Per-host monitoring — scales with infrastructure. Every Kubernetes node, every container host, every VM you run adds a fixed monthly fee. Infrastructure-agent pricing at Datadog runs $15-23/host/month depending on the plan.
• Per-custom-metric — penalizes rich instrumentation. Datadog includes 100 custom metrics per host on Pro; every additional metric costs $0.05/month. A well-instrumented service can easily generate thousands.
• Per-indexed-span / per-analyzed-log — charges you for making data searchable. Ingesting a trace is one cost; indexing it so you can actually query it is another. Datadog's Indexed Spans pricing and Log Analytics pricing are separate line items from base ingestion.
• Per-user seat — limits who can access the observability system. Some platforms charge per-seat fees that restrict how many engineers can view dashboards or run queries.

These dimensions do not grow together in a predictable ratio — they grow independently. A team that doubles its Kubernetes fleet, adds 50% more custom metrics through better instrumentation, and enables trace indexing for a new set of services does not see a 2x increase in their observability bill. They see 4-5x, because each axis multiplied independently.

This is why negotiating a discount on per-GB ingestion pricing does not solve the problem. You can get 30% off the ingestion rate and still see your total bill climb because host counts, custom metrics, and indexed spans are all growing on their own axes. The pricing model has too many independent variables for any single discount to contain it.

Compare this with object storage. S3 costs roughly $0.023 per GB per month. There is one dimension: bytes stored. There is no premium tier for error logs versus debug logs, no surcharge per host that generates the data, no per-metric fee for what the data contains. The economics are flat and neutral — they do not penalize you for keeping more data or instrumenting more thoroughly. The observability data lake model adopts this same single-dimension pricing.

The Consequences Engineers Live With Every Day

The misaligned incentive structure of SaaS observability is not an abstract problem. It produces concrete, daily consequences that engineering teams know well.

Sampling, Data Dropping, and Shrinking Retention

When every gigabyte costs money, teams make trade-offs about what to observe. Debug logs get dropped at the collector level. Traces are sampled at 10% or lower. Verbose services have their log levels raised to WARN or ERROR only. Retention defaults to 7-15 days because extending to 30 or 90 days doubles or triples the cost.

Each decision is rational in isolation, but collectively they create blind spots. The log line you dropped would have explained a 3 AM failure. The trace you sampled away showed the connection pool exhaustion that preceded the outage. The retention window you shortened means a customer-reported issue from three weeks ago is simply gone. You discover these gaps during incidents — precisely when you can least afford them.

Budget Unpredictability

SaaS observability pricing is notoriously difficult to predict. A verbose deployment, a traffic spike, or a Kubernetes autoscaling event can push ingestion volume up 50% in a single day. Engineering leaders end up building internal tooling to monitor their observability spend and implementing hard caps that drop data when budgets are exceeded. The overhead of managing the cost of observability becomes its own operational burden. For a deeper breakdown, see The True Cost of Observability.

Organizational Fear of Instrumentation

Perhaps the most insidious consequence is cultural. When adding instrumentation increases costs, teams become hesitant to instrument. New services launch with minimal logging. Engineers skip trace spans because "it will blow our Datadog budget." The entire premise of observability is that you collect enough telemetry to answer novel questions in real time — the SaaS pricing model punishes exactly this behavior.

Observability Vendor Lock-in: The Compounding Tax

Cost is the most visible problem, but observability vendor lock-in is the one that compounds silently over time.

Proprietary Query Languages

Every major SaaS observability platform uses a proprietary query language — Datadog's syntax, Splunk's SPL, Elastic's KQL. Each is powerful within its platform and useless outside it. After two years, every dashboard, alert rule, and runbook references the vendor's language. The switching cost grows linearly with every month you use the platform.

Proprietary Data Formats

SaaS vendors store data in proprietary formats. You cannot export telemetry in a standard format, run your own analytical tools against it, or build ML models on historical data. Trend analysis, capacity planning, cost attribution — all require access to raw telemetry that is locked inside the vendor's platform.

Open formats like Apache Parquet eliminate this. Parquet on S3 is queryable with DuckDB, Spark, Athena, or any compatible tool. Your data remains yours, independent of your observability platform.

Proprietary Agents and Instrumentation

Many SaaS vendors require proprietary agents that increase dependency — switching platforms means replacing agents across your entire fleet. OpenTelemetry decouples data collection from backends, but vendors often gate advanced features behind their proprietary agents, maintaining a soft lock-in that discourages full adoption of vendor-neutral instrumentation.

The Data Sovereignty Gap

Your observability data contains a detailed operational fingerprint of your systems — API endpoints, user identifiers, error messages, database queries, request paths, and scaling patterns. In the SaaS model, all of this lives on the vendor's infrastructure. For companies in regulated industries — healthcare, finance, government, defense — this creates compliance challenges that range from inconvenient to disqualifying.

Even without strict regulatory requirements, your operational data is an asset that should live on infrastructure you control, encrypted with keys you manage, governed by access policies you define. The SaaS model asks you to trade that control for convenience. The Bring Your Own Bucket model gives you both.

The Architectural Fix: The Observability Data Lake

The fix is not to negotiate a better rate on per-GB pricing. It is to change the architecture so that multi-dimensional pricing cannot exist. When telemetry goes to object storage in open formats, pricing dimensions collapse to one: storage cost per GB per month. The observability platform adds value through compute — queries, alerts, dashboards — but the dominant cost, storage, is commodity infrastructure with single-dimensional pricing. There is no per-host surcharge because object storage does not know what a host is. There is no per-metric fee because Parquet files do not distinguish between a custom metric and a default one. The architecture eliminates the pricing axes, not just the rates.

The observability data lake model corrects the incentive structure by changing where data lives, what format it uses, and how pricing works.

Open Formats as the Foundation

In the data lake model, all telemetry — logs, metrics, and traces — is stored in Apache Parquet on object storage. Parquet is an open, columnar format that provides 70-90% compression over raw JSON, enables column pruning for fast analytical queries, and is readable by every major data processing tool.

The choice of format is not a technical detail; it is an architectural commitment to portability. When your data is in Parquet, you are not locked into any single query engine or vendor. You can switch your observability platform without migrating your data. You can run multiple tools against the same dataset. Your data outlives any vendor relationship. For a full explanation of the observability data lake architecture, see What Is an Observability Data Lake?.

Data Ownership by Default

The data lake model stores telemetry in storage you own — your S3 bucket, your GCS account, your Azure Blob container. The observability platform reads from and writes to your storage, but the data never leaves your infrastructure. You control encryption, access policies, retention, and lifecycle management.

This is not just about compliance. It is about preserving optionality. When you own the data, you can analyze it with any tool, retain it for any duration, and share it with any team. When the vendor owns the data, every access path goes through their platform and their pricing.

Predictable, Aligned Pricing

The data lake model decouples storage cost from the observability platform. Object storage is commodity infrastructure that costs $0.02-0.03 per GB per month, regardless of vendor. The observability platform charges for ingestion processing and query compute, but the dominant cost — storage — is transparent and under your control.

This eliminates the core misalignment. The vendor's revenue is tied to the value of their query engine and operational features, not to the volume of data you store. There is no financial penalty for retaining 12 months of data instead of 15 days. There is no surcharge for adding a new microservice or enabling debug logging during an incident.

Where Parseable Fits: Simplicity and Ownership, Not Either/Or

The most common objection to the data lake model is complexity. Running your own object storage, managing Parquet writers, deploying query engines, and building a UI sounds like a lot of work compared to signing up for a SaaS platform and pasting an API key.

This is where Parseable enters the picture. Parseable is an observability data lake platform that provides two paths depending on what you need.

For teams that want managed simplicity, the Parseable Cloud Pro plan offers a fully managed experience at $0.39/GB ingested. This includes 365 days of retention, 99.9% uptime SLA, AI-native analysis, anomaly detection, unlimited users, dashboards, alerts, and full API access. A 14-day free trial is available. You get predictable pricing and modern capabilities without managing infrastructure. All data is stored in Apache Parquet, and you query with SQL via Prism (Parseable's web UI) or the API. Native OTLP ingestion means you send telemetry with standard OpenTelemetry collectors.

For teams that need full data ownership, the Enterprise plan adds Bring Your Own Bucket (BYOB). Your telemetry lands in Parquet files in your own S3, GCS, or Azure Blob account. You control the storage, encryption, and access policies. Enterprise also includes Apache Iceberg support, premium support, and flexible deployment options — Parseable Cloud, BYOC (Bring Your Own Cloud), or fully self-hosted via a single binary. Enterprise pricing starts at $15,000/year.

This is the key point: you do not have to choose between operational simplicity and data ownership. Parseable Pro gives you the managed SaaS experience without the misaligned incentives. Parseable Enterprise gives you complete data sovereignty when your requirements demand it. Both options store data in open Parquet format. Both use ParseableDB, built on Apache Arrow DataFusion, for fast analytical queries. Both accept telemetry via native OTLP. Neither locks you into a proprietary format or query language.

For teams currently running on a SaaS observability platform and considering migration, see From Datadog to a Data Lake: Migration Guide for a practical walkthrough.

The SaaS Model Served Its Purpose

The SaaS observability model was the right answer for the 2010s, when engineering teams needed monitoring that worked immediately and scaled automatically. Datadog, New Relic, and their peers made observability accessible to teams that could not afford to build and maintain monitoring infrastructure.

The problem is not that the SaaS model was wrong — it is that conditions have changed. Telemetry volumes have grown by orders of magnitude. OpenTelemetry has standardized instrumentation. Object storage and Apache Parquet have matured. The building blocks for a better model exist. The SaaS model was the bootstrap. The data lake model is the steady state.

What Should Change

If you are an engineering leader evaluating your observability strategy, here are the structural questions worth asking:

1. Do you own your observability data? If your vendor disappeared tomorrow, could you access your historical telemetry? If not, you have a dependency, not a partnership.

2. Does better observability mean a bigger bill? If adding instrumentation, extending retention, or enabling debug logging during an incident triggers cost anxiety, the pricing model is working against you.

3. Are you choosing not to observe? If your team has ever dropped log levels, reduced trace sampling, or shortened retention to control costs, the SaaS model is making your systems less observable. That is the opposite of what you are paying for.

If the answers to these questions concern you, it is time to evaluate the data lake alternative. The architecture exists. The tooling is mature. The economics are straightforward.

Conclusion

The SaaS observability model is broken not because vendors are malicious, but because the business model's incentives are misaligned with customer outcomes. Vendors profit from growing data volumes; customers need growing data volumes to maintain visibility but cannot afford the cost. The result is a market where teams pay more every year for observability while simultaneously observing less of their systems.

The observability data lake model corrects this by decoupling storage from compute, using open formats that prevent lock-in, and placing data ownership with the customer. It is not a future concept — it is an architecture running in production today, enabled by the convergence of OpenTelemetry, Apache Parquet, and commodity object storage.

Parseable makes this architecture accessible. Start with the Pro plan on Parseable Cloud for managed simplicity at $0.39/GB with a 14-day free trial, or explore the Enterprise plan for full BYOB data ownership. Either way, your data stays in open Parquet format, your queries use standard SQL, and your observability costs stop being a source of organizational anxiety.

The SaaS model served its purpose. It is time for the correction.