cloudparts

Parseable

A Rust server that stores logs, metrics and traces as Parquet files on object storage and queries them with SQL, without indexing at ingest.

What it is
Observability
Used for
Logs,Distributed tracing,Metrics
Type
Open source
Made by
Parseable
License
AGPL-3.0 (open-source server); Parseable Cloud and Enterprise are commercial
Facts checked
23 October 2026
Website Source code

What it is

Parseable is one binary that contains both the storage engine and its web UI, Prism. Data arrives over HTTP as JSON, as OpenTelemetry (OTLP/HTTP) logs, metrics and traces, or from Kafka; each request names a dataset in the X-P-Stream header. The receiving node converts events to Apache Arrow, writes them to a local staging directory, and every minute converts the staged data to compressed Parquet and uploads it to S3, Google Cloud Storage, Azure Blob or MinIO, along with manifest files that record which columns and time ranges each file holds. Data still in staging can already be queried. Nested JSON is flattened into columns, and the schema is detected from the data.

Queries are PostgreSQL-flavoured SQL run by Apache DataFusion, and each must give a start and end time. The query node reads the manifests, picks only the Parquet files that overlap the time range and filters, and fetches just the needed columns with ranged S3 GETs. Nothing is indexed by default; full-text indexes are built on demand. A standalone node can run on local disk; in distributed mode, nodes take roles (ingestor, querier, indexer and the Prism leader) and coordinate through metadata files in the bucket rather than a consensus service. The open-source build is AGPL-3.0 and supports one query node. Parseable Cloud costs $0.39 per GB ingested with 365 days of retention, and Enterprise, from $15,000 a year, runs in your own cloud or on premises and adds high-availability clusters, a PromQL engine, a hot-tier cache and custom partitioning.

Why teams pick it

  • Object storage is the only dependency, and the data stays as plain Parquet in your bucket, which other engines can read
  • No index is built at ingest, so writing is cheap; filtering by time and column reads only the files and byte ranges a query needs
  • One binary with its own UI, dashboards, alerts and RBAC, and OpenTelemetry logs, metrics and traces accepted without extra configuration
  • SQL over all signals through DataFusion, including regex operators and window functions

Watch out for

  • Open core: the AGPL build has one query node, and HA clustering, PromQL, the hot-tier cache, custom partitioning and the AI features are Cloud or Enterprise only
  • Every query must give a time range, and text search without an on-demand index reads the whole column for every file in that range
  • Data reaches object storage once a minute, so the staging disk must survive a node failure; the docs recommend a redundant volume such as EBS or EFS
  • A distributed deployment can’t be turned back into a standalone one, and the indexer and Prism leader are single nodes

Alternatives

What all observability have in common →Compare side by side →
Grafana LokiOpen sourceA log store that indexes only a few labels per stream, keeps the log lines as compressed chunks in object storage, and greps them at query time with LogQL.IceGateExperimentalOpen sourceA Rust engine that takes OpenTelemetry data and keeps it in Apache Iceberg tables on S3, with Loki- and Tempo-compatible query APIs and Arrow Flight SQL.

How it fits with other technologies

Run Parseable locally, send an event, query it with SQL · bash

# standalone mode on local disk; UI at http://localhost:8000 (admin / admin)
docker run -p 8000:8000 parseable/parseable:edge parseable local-store

# send events to the dataset named in X-P-Stream
curl -u admin:admin http://localhost:8000/api/v1/ingest \
  -H 'X-P-Stream: frontend' -H 'Content-Type: application/json' \
  -d '[{"level": "error", "message": "payment failing", "status": 502},
       {"level": "info", "message": "ok", "status": 200}]'

# SQL over a time range (start can be a duration such as 10m)
curl -u admin:admin http://localhost:8000/api/v1/query \
  -H 'Content-Type: application/json' \
  -d "{\"query\": \"SELECT level, count(*) AS n FROM frontend WHERE message ~ 'fail' GROUP BY level\",
       \"startTime\": \"10m\", \"endTime\": \"now\"}"
# [{"level":"error","n":1}]

See it in a real stack

No architecture uses Parseable yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2022–2026

Nitish Tiwari started Parseable in Bengaluru in 2022, and its first release, v0.0.1, was tagged on GitHub that September. In a December 2022 article he argued that search engines used as log stores index everything at ingest, which costs CPU and slows writes, and that with a columnar format such as Parquet on ordinary object storage, logs can be compressed and queried without an index, and read by other tools such as Spark or Presto.

The project started as log analytics. Version 1.0 in April 2024 added a distributed mode with separate ingest and query nodes, and in May 2024 the company raised a $2.75 million seed round led by Surge and NP-Hard Ventures. Version 2.0 in April 2025 introduced the Prism UI, on-demand indexing and an Enterprise edition built on the AGPL core, with metrics and traces accepted in OpenTelemetry format. Version 3.0 in August 2026 added multi-tenancy, an MCP server and agent observability.

Why it’s built this way

Columnar Parquet files instead of a search index
Indexing every log line at ingest takes CPU and can roughly double storage. Columnar files compress well and let queries read only the columns they need, so Parseable skips the index by default and builds one only when asked.
Object storage as the only persistent store
Buckets are cheap and durable, and they separate storage from compute so ingest and query nodes can scale independently and hold little state of their own.
Stage in Arrow, flush to Parquet every minute
Writing a Parquet file per request would create huge numbers of tiny objects. Batching in a local Arrow staging area makes larger files while keeping fresh data queryable.
Manifests instead of a metadata database
Manifest files in the bucket record which columns and time ranges each Parquet file covers, so the query node can plan without a separate database and fetch only the byte ranges it needs.

Timeline

  1. 2022

    Parseable v0.0.1 released on GitHub in September

  2. 2024

    Version 1.0 adds distributed mode in April; $2.75 million seed round in May

  3. 2025

    Version 2.0 brings Prism, on-demand indexing and an Enterprise edition

  4. 2026

    Version 3.0 in August adds multi-tenancy and an MCP server

Sources13 · facts checked 23 October 2026

Improve this page on GitHub