Parseable: A Rust Telemetry Store That Writes Parquet to Object Storage

The bill Parseable is trying to cut

Observability vendors price on ingest volume and retention. A team that keeps 30 days of logs at high volume pays for a search index it rarely queries in full, and the index is the expensive part. Parseable's stated claim is a reduction in storage cost of up to 90 percent through columnar telemetry compression, achieved by writing telemetry as Parquet on object storage instead of maintaining a proprietary index on block storage. Object storage is roughly an order of magnitude cheaper per gigabyte than provisioned SSD, and Parquet's columnar layout compresses repetitive fields well. The audience is platform and infrastructure teams that already run S3, MinIO or another S3-compatible store, want to keep their existing agents and OpenTelemetry pipelines, and are willing to trade some query flexibility for a much smaller storage bill. It is also aimed at teams that have grown tired of running three systems (a log store, a metrics TSDB and a trace backend) and paying three infrastructure bills for one investigation.

Stateless compute over Parquet, and what that implies

The README describes the architecture as stateless compute over object storage as the backing store, with storage and compute scaling independently. In practice that means the Parseable process accepts writes, buffers them, and flushes columnar files to the object store; queries read those files back. Because the compute tier holds no authoritative state, you can run more query nodes without resizing storage, and storage grows without adding query capacity. The trade-off is inherent to the design: a query that must scan many small files pays object-store latency per file, so file sizing and compaction behaviour matter more than they would in an index-based store. The project positions itself as OpenTelemetry native and as a drop-in replacement for an existing OpenTelemetry Collector setup, which tells you the intended ingest path is OTLP rather than a bespoke agent protocol. Logs, metrics and traces land in the same storage substrate, and the query surface spans SQL and PromQL. Whether that unification is genuinely simpler than running separate stores depends on how much of your querying is SQL-shaped versus how much is full-text search, a distinction the README does not address.

Getting a binary running and a first batch in

The README's quickstart is a single command: curl -fsSL https://logg.ing/install | bash. On Windows it gives powershell -c "irm https://logg.ing/install-windows | iex". The server listens on port 8000 and serves its UI there. The documented ingest example is a POST to http://localhost:8000/api/v1/ingest with three headers: X-P-Stream set to the target stream name (demo in the example), Authorization set to Basic YWRtaW46YWRtaW4= (the base64 of admin:admin), and Content-Type: application/json, with a JSON array body containing fields such as id, datetime and host. The UI is reached at http://localhost:8000 and the documented default credentials are admin / admin. Two things in that example deserve attention. The first is X-P-Stream: streams are the unit of organization, and an ingest request without it has nowhere to go. The second is that the default credentials are published in the README, which is fine for a laptop and unacceptable for anything reachable from a network. The README points to the self-hosted installation guide for hardening, and that guide, not the quickstart, is the document that matters for production. For image integrity, the project attests builds with attest-build-provenance, and the README gives the verification command: gh attestation verify PATH/TO/YOUR/PARSEABLE/ARTIFACT-BINARY -R parseablehq/parseable, which requires a recent GitHub CLI.

Where the single-binary story runs out

The feature list is long: alerting, dashboards, anomaly detection, APM, PromQL and SQL, all in one binary. That breadth is the pitch and also the risk. A single process that ingests, indexes, stores, queries and alerts has one failure domain; if it is unhealthy, you lose ingestion and investigation at the same moment, which is the moment you need both. Nothing in the supplied material describes high availability, replication or a quorum design, so a reader should treat multi-node resilience as unverified and test it before depending on it. The second limitation follows from the storage model. Parquet on object storage is excellent for aggregations over structured fields and poor for interactive full-text search across arbitrary high-cardinality strings, because there is no inverted index to consult; the query engine has to read column data. If your primary use case is grepping application logs for a stack trace fragment across a terabyte, this architecture is working against you. The third is licensing. Parseable is AGPL-3.0. If you modify it and expose it to users over a network, the licence's network-copyleft terms are the thing your legal team will want to read. That is not a reason to avoid the project, but it is a reason to know the answer before an internal fork appears.

How it differs from running Loki or ClickHouse yourself

The obvious comparison for log storage is Grafana Loki, which also avoids a full inverted index and also targets object storage, but Loki's index is a separate small index plus compressed chunks keyed by label set, and its query language is LogQL. Parseable instead writes Parquet and exposes SQL and PromQL over it. The practical difference: with Loki you get label-scoped log search that is fast on narrow label queries and awkward for arbitrary analytical joins; with Parseable you get a columnar file you can also open with any Parquet reader, and analytical queries that look like warehouse SQL. The second comparison is ClickHouse, which many teams reach for as a log backend. ClickHouse gives you a real columnar engine with a mature SQL surface and its own MergeTree storage on local disks; it is faster for interactive queries but you own the storage tier and its replication. Parseable's bet is that object storage plus stateless compute is the cheaper operational shape and that SQL over Parquet is sufficient. The README does not publish benchmark methodology in the repository text, only a link to a benchmarks page, so treat any performance claim, including the 90 percent storage figure, as vendor-supplied until you reproduce it on your own data.

Upgrades, releases and what maintenance actually costs

The release history in the supplied material shows v3.1.0 on 2026-08-18, v3.1.1 on 2026-08-26 and v3.2.0 on 2026-09-06. A bugfix release eight days after a minor release is normal for a project moving this fast, and it also means you should not treat a .0 minor as a stable target. The maintenance cost you are signing up for is not patching a package; it is operating an object store, sizing the compute tier, and managing the Parquet files that accumulate. Because compute is stateless, upgrading the binary is conceptually simple, but the on-disk format is the durable part, so the question that matters at every upgrade is whether the new version reads files written by the old one. The supplied material does not document a format compatibility policy, and that is the single largest unknown for anyone planning a multi-year retention window. The AGPL-3.0 licence has no per-node or per-volume cost, which is the point of choosing it over a commercial backend, but it does carry source-availability obligations for modified network services. Verify the upgrade path on a copy of real data before you rely on it.

The agent and LLM angle, stated plainly

The README lists agent-observability among the topics and says Parseable supports observing AI agents and using LLMs to analyze telemetry data, both natively. The material does not describe the mechanism for either. There is no schema, no SDK name, no prompt interface and no example in the supplied text. That is not evidence the feature is absent, but it is evidence that a reader cannot evaluate it from the repository README alone. If agent observability is why you are looking at Parseable, the integration documentation, not this article, is where the decision gets made. The same caution applies to the anomaly detection and APM entries in the feature list: they are named, not specified. The features that are concretely documented in the material are ingest via HTTP with a stream header, the OpenTelemetry path, SQL and PromQL querying, dashboards and alerting, and the install and attestation commands. Build the evaluation on those.

Editorial conclusion

Adopt Parseable if you already pay for S3-compatible object storage and want one binary to cover ingest, SQL, PromQL and dashboards, and if your team can read Parquet when the UI does not answer a question. Do not adopt it if you need sub-second full-text search over high-cardinality free text, if you cannot accept AGPL-3.0 obligations, or if you have no object storage to point it at. Before committing, verify three things on your own data: the ingest path that matches your agents, the query latency of a PromQL range query at your real retention window, and the upgrade procedure between minor versions, since the release history shows a bugfix release (v3.1.1) landing eight days after v3.1.0. Run the install script, post one batch to /api/v1/ingest with the X-P-Stream header, and look at the Parquet files it leaves behind. That is the whole evaluation.

Official sources

1. License: AGPL-3.0
2. parseablehq/parseable on GitHub
3. Project website
4. README
5. Releases