Parseable: a Rust observability data lake in a single binary

What Parseable is for, and who ends up running it

Parseable targets the gap between a log shipper and a query engine. Most teams wire together a collector, a storage tier, an index, and a dashboard, then pay for each layer separately. Parseable collapses that into one Rust binary that accepts telemetry, writes it as columnar Parquet to object storage, and answers queries from the same process. The README describes it as "purpose built for observability" with "stateless compute over object storage as the backing store."

The intended user is a platform or infrastructure engineer who already has an S3-compatible bucket, an OpenTelemetry pipeline, or a Kafka topic, and who is willing to operate a server. The README lists ingestion via "popular logging agents, OpenTelemetry, Kafka, eBPF or other integrations," so the project assumes you already have producers and only need a destination. It is not aimed at someone who wants a hosted endpoint and a credit card form.

The second audience is less obvious. Because the storage format is Parquet, the data stays readable by other engines. A team that later wants to move to a different query layer keeps its history. That is a real differentiator against systems that own their on-disk format.

The data lake mechanism: Parquet on object storage, DataFusion on top

The dependency list in Cargo.toml is the clearest description of the architecture. Arrow 59.2.0 and parquet 59.2.0 handle the columnar format. datafusion 55.0.0 and datafusion-proto 55.0.0 provide the query engine. object_store 0.13.2 is compiled with the cloud, aws, azure and gcp features, which is how the same binary reaches different storage backends. actix-web 4.9.0 serves the HTTP API and the UI; tonic 0.14.1 provides gRPC, which is what an OpenTelemetry collector would speak; arrow-flight 59.2.0 is present for Arrow Flight.

So the flow is: an agent posts to the ingest endpoint or streams over gRPC, Parseable buffers and writes Parquet objects to the configured bucket, and a query goes through DataFusion against those objects. Compute is described as stateless, which means a query reads from object storage rather than from a local index. That design is what allows storage and compute to be sized independently, and it is also what makes query latency depend on the object store rather than on RAM.

The README claims storage cost reductions "by up to 90% through columnar telemetry compression." Treat that as a vendor figure with no stated baseline. Columnar Parquet with dictionary and run-length encoding genuinely compresses repetitive log fields well, but the number depends entirely on what you send and what you compare against. The repository does not publish the workload behind it in the files available here.

Installing Parseable and sending your first log line

The README gives a one-line installer for Linux and macOS, and a PowerShell equivalent for Windows. It downloads and runs the binary on your machine.

curl -fsSL https://logg.ing/install | bash

On Windows the README gives this instead:

powershell -c "irm https://logg.ing/install-windows | iex"

Once the server is up it listens on port 8000. The README's next example posts a JSON array to the ingest API, naming the target stream in the X-P-Stream header and authenticating with HTTP Basic. The base64 value shown decodes to the default admin/admin pair.

curl --location --request POST 'http://localhost:8000/api/v1/ingest' \
--header 'X-P-Stream: demo' \
--header 'Authorization: Basic YWRtaW46YWRtaW4=' \
--header 'Content-Type: application/json' \
--data-raw '[
    {
        "id": "434a5f5e-2f5f-11ed-a261-0242ac120002",
        "datetime": "24/Jun/2022:14:12:15 +0000",
        "host": "153.10.110.81"
    }
]'

After that request returns, the README says the records are visible in the dashboard at http://localhost:8000, where you log in as admin with password admin. That default credential pair is the single most important thing to change before the server is reachable from anywhere but your laptop; the README points production users at a separate installation guide for "best practices and hardening tips."

For container builds, the repository ships a Dockerfile that compiles with cargo build --release on rust:1.96.0-bookworm and copies the resulting parseable binary into a distroless cc-debian12 image. There is no shell in that final image, so debugging a running container means reading logs rather than exec-ing in. The repository also carries several docker-compose files, including docker-compose-local.yaml and distributed variants with Kafka and GCS, which are the quickest way to see a multi-node layout without writing one.

Where Parseable is the wrong tool

The stateless-over-object-storage design has a cost. Every query reads Parquet objects from the bucket, so interactive dashboards over months of high-cardinality data depend on object store latency and on how well the layout prunes. A system with a local inverted index will feel faster on ad hoc text search, and no amount of Parquet encoding changes that. If your primary workload is grepping recent logs during an incident, a smaller index-based tool is the better fit.

The operational surface is also larger than a single binary suggests. The Cargo.toml shows optional Kafka support behind rdkafka, sasl2-sys and aws-msk-iam-sasl-signer feature flags, which means a Kafka-enabled build pulls in a C toolchain and vendored libraries. The repository ships a Cross.toml and several Dockerfiles (Dockerfile, Dockerfile.debug, Dockerfile.dev, Dockerfile.kafka), which tells you the build matrix is not trivial. If your team cannot build or pin a Rust binary, take the container instead.

Finally, the README does not document rollback. Releases are frequent (v3.1.0, v3.1.1 and v3.2.0 all landed within a month), and nothing in the available files describes what happens to existing Parquet data if you downgrade. That is a gap worth pressing on before you put it in front of a production cluster.

Parseable compared with Grafana Loki and ClickHouse

The topic list names grafana-alternative, so the comparison is fair game. Loki indexes labels rather than content and stores compressed chunks; queries are fast when you filter by label and slow when you need to scan. Parseable writes Parquet and queries it with DataFusion, so full-column scans are the normal path and SQL is the interface. The practical difference: Loki optimizes for cheap label-based retrieval, Parseable optimizes for structured analytical queries over the same objects you could hand to another engine.

ClickHouse is the other common destination for observability data. It is a columnar database with its own MergeTree storage and its own replication model. Parseable does not manage storage at all; it treats a bucket as the source of truth and keeps compute stateless. That is simpler to reason about for durability, because object storage already handles replication, and harder to reason about for query latency, because you cannot rely on local caches the way a ClickHouse cluster can.

PromQL support is listed in the README alongside SQL. That matters if you already have Prometheus-style alerts and dashboards, since it gives you a migration path that does not require rewriting every query. The README does not state which PromQL functions are implemented, so verify coverage against your existing rules before planning a move.

Licence, maintenance and what an upgrade actually costs

Parseable is AGPL-3.0, and the Dockerfile carries the same identifier in its OCI label. The AGPL's network clause is the part that matters here: if you modify Parseable and let users interact with it over a network, the licence obliges you to offer them the corresponding source. Running an unmodified binary as internal infrastructure is a different situation from embedding it in a product you sell. This is not legal advice; if the second case describes you, get a lawyer to read section 13 rather than a blog post.

Maintenance looks current. The last push was on 2026-09-10, the repository is not archived, and v3.2.0 was released on 2026-09-06. Three releases shipped between 2026-08-18 and 2026-09-06, so the cadence is roughly weekly at the moment. Cargo.toml pins rust-version = 1.94.0 with edition 2024, and the Dockerfile builds on rust:1.96.0-bookworm, so anyone compiling from source needs a recent toolchain.

Upgrade cost is dominated by schema and storage compatibility, not by the binary swap. Because the data lives in your bucket, a failed upgrade leaves the objects intact, but the available files do not describe a downgrade path or a migration tool. The Makefile offers helm upgrade --install against helm/parseable, which suggests Helm is the supported deployment route for Kubernetes. Before upgrading, snapshot the bucket and read the release notes for the version you are moving to; the README itself says nothing about compatibility guarantees between minor versions.

Editorial conclusion

Adopt Parseable if you already operate S3-compatible object storage, want telemetry in Parquet you can query with other engines, and can run a Rust binary or container yourself. Do not adopt it if you want a fully managed backend, need a documented rollback path before upgrading, or cannot accept the AGPL-3.0 network-copyleft terms. Verify first that your target storage backend is among the ones the Cargo.toml features list (aws, azure, gcp), that your ingest agents speak one of the documented protocols, and that you have a tested backup of the object store bucket, since the README documents no rollback procedure for a version downgrade.

Frequently asked questions

Official sources

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