Why S3-Native Log Analytics Is the Future (And How to Get Started)

Updated: February 2026 | Reading time: 18 min

Introduction

The observability industry is undergoing a structural shift. For over a decade, log analytics meant maintaining dedicated indexing clusters — Elasticsearch nodes with terabytes of SSD storage, Splunk indexers burning through enterprise budgets, or ClickHouse shards demanding constant tuning. Every platform assumed the same thing: that logs needed to live on expensive, purpose-built infrastructure to remain queryable.

That assumption is no longer true.

S3-native log analytics — the practice of storing, indexing, and querying observability data directly on object storage — represents the third and most consequential architectural evolution in the history of log management. It is not an incremental improvement. It is a category shift that changes the economics, scalability, and operational model of observability from the ground up.

This article traces the full arc of that evolution, explains why S3-native architectures win on every dimension that matters, and shows you how to get started with a platform purpose-built for this paradigm: Parseable.

TL;DR: S3-native log analytics stores observability data in open columnar formats (Apache Parquet) directly on object storage, delivering 100x cost reduction, infinite retention, zero capacity planning, and zero vendor lock-in. Parseable is the first unified observability platform (logs, metrics, traces) purpose-built for this architecture — deployed as a single Rust binary.

The Three Eras of Log Analytics

To understand why S3-native log analytics matters, you need to understand where the industry has been and why each prior generation hit a ceiling.

Era 1: Traditional Log Analytics (2010 - 2018)

The first generation of modern log analytics was defined by platforms that stored logs on local disk with proprietary indexing engines. Elasticsearch and Splunk were the defining technologies of this era.

Elasticsearch popularized the ELK stack (Elasticsearch, Logstash, Kibana), bringing full-text search to log data through Apache Lucene inverted indexes. It was a revelation — for the first time, engineering teams could search across millions of log lines in seconds. But the architecture carried fundamental constraints. Elasticsearch required careful shard management, hot-warm-cold tier planning, and substantial SSD storage. Running a production cluster at scale demanded a dedicated team.

Splunk took a different path, building a proprietary indexing engine optimized for machine data. SPL (Search Processing Language) became the de facto standard for security analysts and IT operations teams. But Splunk's value came at a price that became legendary in the industry: $2,000+ per GB/day of ingestion. At scale, Splunk licenses alone could exceed the cost of the infrastructure being monitored.

The fundamental limitation of Era 1 was coupling compute and storage. Every query node needed local access to indexed data. Scaling meant adding more nodes with more SSDs. Retention was bounded by disk capacity and budget. Most organizations could afford 7 to 30 days of searchable logs, discarding everything older — precisely the data that forensic investigations and compliance audits would later demand.

Era 2: Cloud-Native Log Analytics (2018 - 2023)

The second generation recognized that object storage could solve the cost and retention problems of Era 1. Grafana Loki, AWS CloudWatch Logs, and similar platforms began writing log data to S3-compatible backends.

Grafana Loki was the most architecturally interesting of this generation. It stored log chunks on object storage and indexed only metadata labels, not log content. This was a deliberate trade-off: by abandoning full-text search, Loki could deliver dramatically lower storage costs. If you knew the right labels, queries were fast. If you needed to search inside log lines, you were doing a brute-force scan across potentially millions of compressed chunks.

AWS CloudWatch Logs offered managed log storage on S3, but with a proprietary query engine (CloudWatch Logs Insights), limited analytical capabilities, and pricing that scaled poorly beyond basic use cases. Cross-account and cross-region querying remained cumbersome.

The fundamental limitation of Era 2 was the compromise. These platforms proved that object storage could work for logs, but each sacrificed something essential to make it happen. Loki gave up full-text search. CloudWatch gave up query flexibility. None delivered unified observability across logs, metrics, and traces on a single storage backend. And none adopted truly open data formats — your data was still stored in proprietary chunk formats that only the originating platform could read.

Era 3: S3-Native Log Analytics (2024 - Present)

The third generation eliminates the compromises. S3-native log analytics means storing observability data in open, industry-standard columnar formats — specifically Apache Parquet — directly on object storage, while retaining full query capabilities including full-text search, SQL analytics, and cross-signal correlation.

This is not "logs on S3 with limitations." This is full observability on S3 with no compromises.

Parseable is the defining platform of this era. Built from scratch in Rust, Parseable stores logs, metrics, and traces in Apache Parquet format on any S3-compatible object store. It queries that data using Apache Arrow DataFusion, a high-performance SQL engine designed for columnar data. The result is a platform that delivers:

• Full-text search across log content (not just labels)
• Standard SQL queries with joins, aggregations, and window functions
• Sub-second query performance through columnar pruning and predicate pushdown
• Infinite retention at S3 storage prices ($0.023/GB/month)
• Complete separation of compute and storage
• Open data formats readable by any Parquet-compatible tool

Why S3 Changes Everything

The shift to S3-native log analytics is not a marginal improvement. It restructures the economics, operational model, and data strategy of observability. Here is why.

Economics: 100x Cost Reduction

The cost difference between traditional log storage and S3-native storage is not 2x or 5x. It is two orders of magnitude.

Amazon S3 Standard storage costs $0.023 per GB per month. With Parquet columnar compression achieving 80-90% compression ratios on typical log data, 1 TB of raw logs compresses to approximately 100-200 GB on disk.

Compare this to traditional approaches:

At enterprise scale — 10 TB/day of log ingestion — the annual savings approach $1 million or more. This is not a theoretical calculation. It is the direct result of replacing proprietary indexing infrastructure with commodity object storage.

The cost advantage compounds with retention. Traditional platforms force you to delete data to control costs. S3-native platforms make it economical to retain everything. Storing a full year of 1 TB/day log data on S3 costs roughly $10,000. On Splunk, that same year of data would cost over $700,000 in licensing alone. This changes the fundamental calculus of log retention from "how little can we keep?" to "why would we ever delete anything?"

Scale: S3 Is Effectively Infinite

Amazon S3 stores over 350 trillion objects as of 2024. It has no maximum bucket size, no maximum object count, and no throughput ceiling that any observability workload will realistically hit. When your log analytics platform stores data on S3, you inherit that scale for free.

There is no capacity planning. No shard rebalancing. No hot-tier-to-cold-tier migration scripts. No 3 AM pages because a disk filled up. No ordering new NVMe drives because your Elasticsearch cluster hit 85% disk utilization. The storage layer simply works, at any scale, without intervention.

This matters enormously for operational teams. Capacity planning for traditional log platforms is a specialized skill that consumes significant engineering time. You must forecast growth, provision infrastructure ahead of demand, and manage the inevitable mismatches between predictions and reality. S3-native platforms eliminate this entire category of operational work.

Durability: 11 Nines

Amazon S3 provides 99.999999999% (11 nines) durability. This means that if you store 10 million objects on S3, you can expect to lose a single object once every 10,000 years.

No self-managed Elasticsearch cluster, no Splunk indexer farm, and no ClickHouse replication topology comes close to this durability guarantee. Traditional platforms achieve durability through replication — storing 2x or 3x copies of your data across nodes — which further multiplies storage costs. S3 handles replication transparently, across multiple availability zones, at no additional cost for standard storage.

For compliance-sensitive industries — finance, healthcare, government — this durability guarantee is not just a nice-to-have. It is a regulatory requirement that S3 satisfies out of the box, without any additional architecture.

Open Formats: Zero Lock-In

This is perhaps the most strategically important advantage of S3-native log analytics, and it is the one most often overlooked.

When Parseable writes your logs to S3 in Apache Parquet format, that data is not locked into Parseable. It is standard Parquet. Any tool in the modern data ecosystem can read it:

• Apache Spark can run distributed analytics across your log data
• DuckDB can query individual Parquet files from a laptop
• Amazon Athena can run serverless SQL queries directly against your S3 bucket
• Trino/Presto can join your log data with your data warehouse tables
• Pandas/Polars can load Parquet files for ad hoc analysis in Python
• dbt can transform your log data as part of your analytics pipeline

This is a fundamental shift in the relationship between observability platforms and the data they manage. With traditional platforms, your data is trapped in proprietary formats (Splunk's tsidx, Elasticsearch's Lucene segments, Loki's compressed chunks). Migrating away means re-ingesting everything. With S3-native Parquet storage, your data is always yours, always portable, and always accessible through the tool of your choice.

For CTOs and platform architects, this eliminates the single largest risk of any observability investment: the cost of switching vendors. Your data format is a standard. Your storage is commodity infrastructure. Your query language is SQL. There is nothing proprietary to escape from.

Separation of Compute and Storage

Traditional log analytics platforms couple compute and storage on the same nodes. Your Elasticsearch data nodes serve both as storage and as query processors. When you need more query capacity, you add nodes that also add storage you may not need. When you need more storage, you add nodes that also add compute you may not need.

S3-native architectures decouple these entirely. Storage is S3 — it scales independently, costs pennies, and requires no management. Compute is the query engine — it scales independently based on query concurrency and complexity.

This means you can:

• Scale query compute to zero during off-peak hours and pay nothing for idle infrastructure
• Burst compute capacity during incident investigations without moving or replicating data
• Run multiple independent query engines against the same data for different teams or use cases
• Upgrade or replace the compute layer without any data migration

The data lakehouse pattern that transformed data analytics is now arriving in observability. S3-native log analytics is the observability lakehouse.

What S3-Native Log Analytics Actually Means

The term "S3-native" is specific and important. It does not mean "can export to S3" or "uses S3 as a backup tier." It means the platform's primary, default, and only persistence layer is S3-compatible object storage. The distinction matters.

S3 as a tier (what most platforms do): Data is ingested into a local storage engine first. After some period — hours, days, or weeks — data is moved to object storage as a cold tier. Queries against recent data hit local storage; queries against older data either fail, are slow, or require rehydration. The platform still depends on local infrastructure for its core functionality.

S3-native (what Parseable does): Data is written directly to S3 in its final format from the moment of ingestion. There is no intermediate storage layer. There is no tiering process. There is no local state that needs to be backed up or replicated. The platform operates statelessly against S3 as its single source of truth.

This distinction has profound operational implications:

1. Recovery is instant: If a Parseable node fails, you start a new one. It reads state from S3. There is no data recovery, no rebuild process, no replication lag.

2. Horizontal scaling is trivial: Adding query capacity means starting more stateless compute nodes. They all read from the same S3 data. There is no data redistribution, no shard rebalancing.

3. Multi-region is straightforward: S3 cross-region replication gives you a disaster recovery copy of all observability data. Point a Parseable instance at the replica bucket and you have a fully functional DR environment.

4. Upgrades are non-events: Because there is no local state, upgrading Parseable means deploying a new version. There is no data migration, no index rebuild, no compatibility matrix.

The Apache Parquet + Arrow Advantage

The choice of storage format is as important as the choice of storage backend. Parseable uses Apache Parquet for persistence and Apache Arrow for in-memory query processing. This combination is not accidental — it is the most performant pairing available for analytical workloads on columnar data.

Why Parquet for Logs

Apache Parquet is a columnar storage format originally developed for the Hadoop ecosystem and now the de facto standard for analytical data. Its properties align precisely with log analytics requirements:

Columnar storage: Log queries typically access a small subset of fields. A query like SELECT timestamp, message FROM logs WHERE level = 'ERROR' only needs to read three columns out of potentially dozens. Parquet's columnar layout means the query engine skips all irrelevant columns entirely, reading a fraction of the data that a row-oriented format would require.

Predicate pushdown: Parquet files contain min/max statistics for each column in each row group. The query engine uses these statistics to skip entire row groups (blocks of rows) that cannot contain matching data. For time-range queries — the most common pattern in log analytics — this means the engine reads only the row groups that overlap with the requested time window.

Compression: Parquet supports multiple compression codecs (Snappy, Zstandard, LZ4, Gzip) and achieves exceptional compression ratios on log data because columnar layout groups similar values together. Repeated fields like log levels, service names, and HTTP methods compress to nearly nothing. Typical compression ratios on real-world log data range from 5:1 to 10:1.

Schema evolution: As your logging schema changes — new fields added, types modified — Parquet handles schema evolution gracefully. Old files remain readable, and new files include the updated schema. There is no need to reindex or reprocess historical data.

Ecosystem compatibility: Parquet is readable by virtually every tool in the modern data stack. This is the open-format advantage discussed earlier, and it stems directly from the choice of Parquet as the storage format.

Why Arrow for Query Processing

Apache Arrow is an in-memory columnar format designed for zero-copy data access and SIMD-accelerated processing. Parseable uses Arrow DataFusion as its SQL query engine, which operates directly on Arrow-formatted data.

Zero serialization overhead: Arrow's in-memory format is designed to be operated on directly without deserialization. When Parquet data is read from S3, it is decoded into Arrow format once, and all subsequent operations (filtering, aggregation, sorting, joining) happen directly on the Arrow buffers.

Vectorized execution: Arrow DataFusion processes data in batches (record batches) using vectorized operations that exploit modern CPU SIMD instructions. A filter operation that would process one row at a time in a traditional engine processes thousands of values simultaneously in a single CPU instruction.

Rust performance: Both Arrow and DataFusion are implemented in Rust, eliminating garbage collection pauses and providing predictable, low-latency performance. This matters for real-time log tailing and interactive query workloads where consistent sub-second response times are expected.

The Parquet + Arrow combination means Parseable can deliver analytical query performance that matches or exceeds dedicated OLAP databases like ClickHouse — while storing data on commodity object storage at 100x lower cost. That is the core technical insight that makes S3-native log analytics practical.

Parseable: The S3-Native Observability Platform

Parseable is not just an S3-native logging tool. It is the first unified observability platform — covering logs, metrics, events, and traces — purpose-built from the ground up for S3-native storage. This distinction matters because observability is not a single-signal problem. Debugging a production incident requires correlating log entries with metric anomalies and distributed traces. A platform that handles only one signal type forces you to maintain multiple systems, multiple storage backends, and multiple query interfaces.

Parseable unifies all of this on a single architecture.

Architecture

Parseable is a single Rust binary. It has no external dependencies other than an S3-compatible object store. There is no Kafka, no Zookeeper, no Redis, no PostgreSQL, no sidecar processes. The binary handles:

• Ingestion: HTTP and gRPC endpoints accepting OTLP (OpenTelemetry Protocol), JSON, and other common formats
• Storage: Direct writes to S3 in Apache Parquet format with configurable partitioning
• Query: SQL via Apache Arrow DataFusion with full-text search, aggregations, joins, and window functions
• Visualization: Built-in web console with live tail, dashboards, SQL editor, and alerting
• Alerting: Configurable alerts based on SQL conditions with webhook, Slack, and email targets
• Access control: Role-based access control with OAuth2/OIDC integration

The binary footprint is under 50 MB. Memory usage starts at approximately 50 MB and scales based on query concurrency. This is not a stripped-down demo — it is the same binary that powers production deployments processing millions of events per second. For teams that want S3-native observability without managing any infrastructure, Parseable Cloud provides a fully managed service with a free tier.

Full MELT Observability

Parseable handles all four observability signals:

Logs: Structured and unstructured log ingestion with automatic schema detection. Full-text search across log content. SQL analytics with aggregations, time-series analysis, and pattern extraction.

Metrics: Native metrics ingestion and storage. Time-series queries with standard SQL window functions. Dashboard visualization with built-in charting.

Events: Custom event ingestion for business-level telemetry. Correlate application events with infrastructure signals.

Traces: Distributed trace ingestion via OTLP. Trace visualization, span analysis, and latency breakdowns. Cross-reference traces with logs from the same request using trace IDs.

All four signal types are stored in Parquet on S3. All four are queryable through the same SQL interface. Cross-signal correlation is a SQL JOIN, not a manual context switch between different tools.

OpenTelemetry Native

Parseable provides native OTLP endpoints for both HTTP and gRPC. This means any application instrumented with OpenTelemetry can send logs, metrics, and traces directly to Parseable without translation layers, proprietary agents, or format conversion. The OpenTelemetry Collector can be configured to export to Parseable as a backend in minutes.

As the industry converges on OpenTelemetry as the universal telemetry standard, having a native OTLP receiver is not optional — it is a baseline requirement. Parseable treats OTLP as a first-class citizen, not a bolt-on integration.

AI-Native Analysis

Parseable integrates with large language models to enable natural language log analysis. Engineers can ask questions in plain English — "What caused the spike in 500 errors on the payment service in the last hour?" — and receive structured answers derived from actual log data. This capability is powered by the same SQL engine, with the LLM translating natural language into SQL queries and interpreting the results.

Cloud and Self-Hosted Deployment

Parseable Cloud is the fastest way to get started — a fully managed service starting at $0.37/GB ingested ($29/month minimum) with a free tier. For teams that need infrastructure control, Parseable is available as a self-hosted deployment with source code on GitHub. There is no "open core" bait-and-switch where essential features are gated behind a proprietary enterprise edition. The observability platform you evaluate is the one you deploy.

Why Parseable Leads the S3-Native Category

Parseable did not retrofit S3 support onto an existing architecture. It was designed from day one with S3 as the primary storage layer. Every architectural decision — the choice of Parquet, the choice of Arrow, the stateless compute model, the single-binary deployment — flows from this foundational commitment.

This is why Parseable delivers capabilities that retrofitted platforms cannot match:

• No tiering complexity: Data goes to S3 immediately. There is no hot/warm/cold tier to configure.
• No rehydration delays: All data is always queryable. There is no waiting for data to be moved back to a fast tier.
• No local state to manage: Nodes are stateless. Failure recovery is instant. Scaling is trivial.
• No format conversion: Data is written once in Parquet. No conversion, no compaction, no index rebuild.

For a detailed comparison of how Parseable compares to legacy platforms, see our guides on Parseable vs Elasticsearch, Parseable vs Splunk, Grafana Loki vs Parseable, Elasticsearch vs Parseable Architecture Comparison, and ClickHouse vs Parseable.

Getting Started with S3-Native Log Analytics

Moving to S3-native log analytics with Parseable takes minutes, not weeks. Here are three paths depending on your environment.

Option 1: Docker (Quickest Start)

Run Parseable with local S3-compatible storage for evaluation:

docker run -p 8000:8000 \
  parseable/parseable:latest \
  parseable local-store

This starts Parseable with built-in local object storage. Open http://localhost:8000 and log in with the default credentials to access the built-in console.

Option 2: Connect to S3

For production use, point Parseable at your S3 bucket:

docker run -p 8000:8000 \
  -e P_S3_URL=https://s3.amazonaws.com \
  -e P_S3_ACCESS_KEY=your-access-key \
  -e P_S3_SECRET_KEY=your-secret-key \
  -e P_S3_BUCKET=your-parseable-bucket \
  -e P_S3_REGION=us-east-1 \
  parseable/parseable:latest \
  parseable s3-store

Option 3: Kubernetes with Helm

For production Kubernetes deployments:

helm repo add parseable https://charts.parseable.com
helm repo update
helm install parseable parseable/parseable \
  --set parseable.store=s3-store \
  --set s3.url=https://s3.amazonaws.com \
  --set s3.accessKey=your-access-key \
  --set s3.secretKey=your-secret-key \
  --set s3.bucket=your-parseable-bucket \
  --set s3.region=us-east-1

Option 4: Parseable Cloud (Recommended — Zero Infrastructure)

Sign up at Parseable Cloud for a fully managed deployment starting at $0.37/GB ingested ($29/month minimum) with a free tier. Point your OpenTelemetry Collector at the cloud endpoint and start querying with SQL immediately — no servers, no S3 buckets, no binaries to manage.

Send Your First Logs

Once Parseable is running, send logs using curl:

curl -X POST http://localhost:8000/api/v1/logstream/myapp \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Basic YWRtaW46YWRtaW4=' \
  -d '[
    {
      "timestamp": "2026-02-18T10:00:00Z",
      "level": "info",
      "service": "api-gateway",
      "message": "Request processed successfully",
      "duration_ms": 42,
      "trace_id": "abc123"
    }
  ]'

Configure OpenTelemetry Collector

To send telemetry from your existing OpenTelemetry instrumentation:

# otel-collector-config.yaml
exporters:
  otlphttp:
    endpoint: "http://parseable:8000/v1"
    headers:
      Authorization: "Basic YWRtaW46YWRtaW4="
 
service:
  pipelines:
    logs:
      exporters: [otlphttp]
    traces:
      exporters: [otlphttp]
    metrics:
      exporters: [otlphttp]

Query Your Data with SQL

Once data is flowing, query it with standard SQL:

-- Find error patterns in the last hour
SELECT level, service, count(*) as error_count
FROM myapp
WHERE level = 'error' AND timestamp > NOW() - INTERVAL '1 hour'
GROUP BY level, service
ORDER BY error_count DESC;
 
-- Calculate p99 latency by service
SELECT service,
       approx_percentile_cont(duration_ms, 0.99) as p99_latency
FROM myapp
WHERE timestamp > NOW() - INTERVAL '24 hours'
GROUP BY service;
 
-- Correlate logs with trace spans
SELECT l.message, l.level, t.span_name, t.duration_ms
FROM app_logs l
JOIN traces t ON l.trace_id = t.trace_id
WHERE t.duration_ms > 1000
ORDER BY t.duration_ms DESC
LIMIT 50;

For managed deployments, Parseable Cloud offers a free tier with zero infrastructure to manage.

The Future of Observability: Five Predictions

The shift to S3-native log analytics is not happening in isolation. It is part of a broader restructuring of the observability market. Here is where the industry is heading.

1. Object Storage Becomes the Default for All Telemetry

By 2028, the majority of new observability deployments will use object storage as their primary persistence layer. The economics are too compelling to ignore. Platforms that require dedicated storage infrastructure will be viewed the same way on-premises email servers are viewed today — technically functional, but anachronistic.

2. Open Formats Replace Proprietary Indexes

Apache Parquet and Apache Iceberg will become the standard formats for observability data, just as they have for data analytics. Organizations will demand that their telemetry data be portable and queryable by any tool. Proprietary formats will be a dealbreaker in procurement evaluations.

3. Observability and Data Analytics Converge

When your logs, metrics, and traces are stored in Parquet on S3, the boundary between observability and data analytics dissolves. The same data that an SRE uses for incident investigation becomes available to business analysts for product intelligence, to security teams for threat hunting, and to ML engineers for training anomaly detection models. The observability data lakehouse will become a standard architectural pattern.

4. Compute-on-Demand Replaces Always-On Clusters

The separation of compute and storage enables a pay-for-what-you-query model. Instead of maintaining always-on query clusters sized for peak load, organizations will spin up compute for specific investigations and let it scale to zero when idle. This further reduces the cost gap between S3-native platforms and traditional architectures.

5. AI-Driven Analysis Becomes Table Stakes

When all observability data is in SQL-queryable columnar formats, AI agents can interact with it through natural language. The combination of LLMs and SQL engines will make it possible for any engineer — not just observability specialists — to investigate production issues, identify trends, and build dashboards through conversation. Platforms that do not support this interaction model will fall behind rapidly.

Frequently Asked Questions

Is S3 fast enough for real-time log queries?

Yes, with the right architecture. Parseable uses intelligent caching and Apache Arrow's vectorized query engine to deliver sub-second query performance on data stored in S3. For live tail (streaming recent logs), Parseable maintains a small in-memory buffer that serves real-time queries before data is flushed to S3. The perception that S3 is "slow" comes from naive implementations that scan entire buckets. Parquet's columnar format with predicate pushdown and partition pruning means the query engine reads only the data it needs, which is typically a fraction of a percent of the total dataset.

How does S3-native compare to Elasticsearch for full-text search?

Elasticsearch's inverted index provides the fastest possible exact-term lookup for single keywords. For this narrow use case, Elasticsearch is faster. However, for the analytical queries that dominate real-world observability — aggregations, time-range filters, pattern detection, cross-field correlation — Parquet's columnar format on S3 is faster and dramatically cheaper. Parseable supports full-text search through columnar scanning with Arrow's string processing, which is fast enough for interactive use and does not require the operational overhead of maintaining Lucene indexes. See our detailed Parseable vs Elasticsearch comparison for benchmarks.

What happens if Parseable goes down? Is my data safe?

Your data is on S3, which provides 11 nines of durability independently of Parseable. If a Parseable node crashes, you start a new one. It reads the catalog from S3 and is immediately operational. There is no data loss, no recovery process, and no replication lag. This is fundamentally different from traditional platforms where a node failure can mean lost data unless replication is correctly configured.

Can I use Parseable alongside my existing observability stack?

Yes. Parseable accepts data via standard protocols (OTLP, HTTP JSON) and can run alongside existing tools. A common migration pattern is to dual-ship logs to both the existing platform and Parseable during evaluation. Since Parseable's storage cost is minimal, the cost of running in parallel is negligible. You can also use Parseable's Parquet data with Grafana for visualization if your team already has Grafana dashboards.

What S3-compatible storage backends does Parseable support?

Parseable works with any S3-compatible object store: AWS S3, Google Cloud Storage (via S3 compatibility), Azure Blob Storage (via S3 compatibility), MinIO, Tigris, Ceph, Wasabi, Backblaze B2, and others. For on-premises deployments, MinIO is the most commonly used backend. The storage layer is abstracted — switching from one S3-compatible backend to another requires only changing environment variables.

How does Parseable handle high-cardinality data?

High cardinality — fields with many unique values like user IDs, trace IDs, or IP addresses — is the Achilles heel of label-based systems like Grafana Loki and Prometheus. Parseable does not use label-based indexing. It stores raw data in Parquet columns and queries it with Arrow. High-cardinality fields are simply columns with many distinct values, which Parquet handles efficiently through dictionary encoding and run-length encoding. There is no cardinality explosion, no index bloat, and no special configuration required.

Start Building on S3-Native Observability

The transition from traditional log analytics to S3-native observability is not a future possibility. It is happening now. The organizations adopting this architecture today are gaining structural cost advantages and operational simplicity that compound over time. Every month you continue running expensive indexing clusters is a month of savings left on the table.

Parseable makes this transition practical. A single binary. S3 storage. SQL queries. Full MELT observability. Open source.

• Start with Parseable Cloud — starts at $0.37/GB, free tier available
• Self-hosted deployment — single binary, deploy in 2 minutes
• Read the docs — guides, API reference, and tutorials
• Join our Slack — community and engineering support