LoginSign Up
← Back to all sparks
P

Parseable

ANALYTICS
Velocity6.3

Log analytics platform built for high-volume observability data

www.parseable.com ↗

After 3.0 turned it into an observability console, Parseable is hardening the query path.

observabilitylogsalertingopentelemetryquery-performancemulti-tenancy
◆Current state
Parseable shipped 3.0 in early August, pulling alerting, dashboards, traces and an APM view into what had been a log-storage engine, and moving ingestion onto an OpenTelemetry collector. The releases since are consolidation: alert evaluation correctness across multiple datasets and aggregates, query throttling, OIDC configurability, and a steady retirement of older API surface. The 2.9 line that preceded it was largely ingestion performance and multi-tenant security work.
◆Where it's heading
The shape of the work has shifted from making ingestion cheap to making query and alerting trustworthy. Throttling on queries and repeated fixes to alert aggregate evaluation are what a system starts shipping once users point real dashboards at it, and the deprecation of the role API suggests the access-control surface is being reshaped rather than extended. Security work — SSRF, path traversal, SQL injection sanitization, credential masking — has been a constant across both lines.
◆Prediction
Expect the 3.1 line to continue as patch releases against alerting and query stability, with the deprecated role API replaced by a newer access-control endpoint rather than simply removed.

◆Recent moves

  1. 20d ago

    Query throttling arrives; role API deprecated

    Labelled a bugfix release, but it carries query throttling and a deprecation of the GET /role API alongside the fixes. The alert repairs — SQL alerts spanning multiple datasets, corrected aggregate evaluation — are the follow-through on 3.0's alerting push, addressing the cases that only surface once people write real rules against it.

    View source ↗
  2. 1mo ago

    Parseable 3.0 adds PromQL alerts, APM and dashboard templates

    ⚡ SPARK

    The release where the 2.9 line's plumbing work becomes a product story: alerting, dashboards, tracing and APM ship together, and ingestion moves onto an OpenTelemetry collector. It marks the point where Parseable stops being only the storage tier.

    View source ↗
  3. 1mo ago

    Kafka ingestion gains AWS MSK IAM authentication

    MSK IAM authentication via SASL/OAUTHBEARER plus a configurable OAuth provider makes Kafka ingestion viable for AWS shops without static credentials — the kind of integration detail that decides whether a managed-Kafka team can adopt Parseable at all. Two security fixes land alongside it: SSRF in alert targets and path traversal in the filters API on local storage.

    View source ↗
  4. 2mo ago

    Security pass: SQL injection, API key risk, multi-tenant middleware

    A patch release weighted toward security rather than features — sanitizing array elements to prevent SQL injection, closing an API key risk, fixing OIDC sync and redirect, and repairing multi-tenant middleware. This is the hardening that runs underneath the 2.9 line's multi-tenancy work before 3.0 raised the stakes.

    View source ↗
  5. 2mo ago

    API keys and top-k grouping in the counts API

    A short release introducing API keys and top-k support in the counts API's group-by. API keys are a prerequisite for programmatic and machine access, and they recur in later cuts as the ingest-side key work — an early piece of the access-control surface now being reshaped in 3.1.

    View source ↗
  6. 2mo ago

    Log context API and per-tenant ingestion quotas

    A log context API with start and end time support, plus optional per-tenant ingestion quotas — two features that point at the same thing, operating Parseable for multiple teams rather than one. Eviction switching to insertion time instead of data time is a subtle but meaningful change for anyone backfilling historical logs.

    View source ↗