Changelog | Stornamics

Product updates

Changelog

Review shipped improvements, launch updates, and product changes across the Stornamics platform.

Latest updates

Recent product changes and release notes.

Message Broker 0.6: Replication Control Plane

Message Broker 0.6 implemented replication control-plane routes while keeping cross-site durability, failover, and Kafka compatibility claims bounded.

Message Broker 0.6 implemented the technical replication control plane for the product.

Added

  • Added replication status routes.
  • Added polling behavior for replication state.
  • Added pause and resume routes for replication control.
  • Added target-apply routes for replication targets.
  • Established the technical foundation for replication control-plane evaluation.

Looking Ahead

The next major milestone for Message Broker is proving customer-facing distributed broker outcomes with enough public evidence to support stronger claims around cross-site durability, failover, and compatibility.

Notes

This entry records a technical implementation milestone. It does not claim that cross-site durability or failover has been proven for customer production use. Kafka compatibility also remains prototype-level at this point, with no Kafka wire listener included in this milestone.

Message Broker 0.5: Operations and Security Surface

Message Broker 0.5 added operational, security, diagnostic, CLI, and SDK surfaces around the broker data plane.

Message Broker 0.5 added the operational and security surfaces needed around the broker data plane.

Added

  • Added health and metrics surfaces.
  • Added audit query and export behavior.
  • Added diagnostics and storage inspection.
  • Added API-key, mTLS, and trusted-header authentication modes.
  • Added CLI functionality for broker workflows.
  • Added a Rust SDK for product integration work.

Looking Ahead

The next goal for Message Broker was to add replication control-plane routes while keeping customer-facing durability, failover, and protocol-compatibility claims bounded by evidence.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

ObjectDB 0.6: Private Beta Product Surface

ObjectDB 0.6 brought the product to a coherent private-beta evaluation surface for S3 gateway workflows, SDK patterns, limits, and deterministic failures.

ObjectDB 0.6 brought ObjectDB to a coherent private-beta product surface.

Added

  • Added a customer evaluation path for starting ObjectDB and connecting through the S3 gateway.
  • Added real SDK and client patterns for supported workflows.
  • Added clearer limits and compatibility boundaries around the supported profile.
  • Added deterministic failure behavior for requests outside the supported surface.
  • Connected the service, gateway, examples, limits, and operational notes into a more complete evaluation loop.

Looking Ahead

The next major milestone for ObjectDB is production and distributed ObjectDB: native versions, manifests, placement behavior, customer-grade authorization, broader durability evidence, replication, and larger-scale storage.

Notes

This entry records the private-beta evaluation surface. It does not represent general availability, unrestricted production support, or an unlimited compatibility profile.

LogDB 0.6: Portable Storage and Replay Foundation

LogDB 0.6 established the architectural foundation for portable storage, S3-backed query reads, BYOC preflight artifacts, and replay coordination.

LogDB 0.6 established the architectural foundation for portable storage and replay.

Added

  • Added query reads from segment bundles in configured S3 storage.
  • Added Terraform artifacts for offline BYOC preflight work.
  • Added Helm artifacts for offline BYOC preflight work.
  • Added replay coordinator foundations.
  • Added replay checkpoint and audit foundations.
  • Established the basis for portable-storage and replay evaluation.

Looking Ahead

The next major milestone for LogDB is completing the public product surface around live ingest-to-S3 publication, production BYOC acceptance, public replay APIs, and external replay sinks.

Notes

This entry records an architectural foundation milestone. It does not claim completed live ingest-to-S3 publication, production BYOC acceptance, public replay APIs, or external replay sinks.

Message Broker 0.4: Shared Queue Semantics

Message Broker 0.4 added shared-queue delivery semantics with claiming, leases, acknowledgement, retries, and dead-letter flows.

Message Broker 0.4 added full shared-queue semantics, giving the product both stream and work-queue behavior.

Added

  • Added message claiming with persisted delivery state.
  • Added lease and lease-renewal behavior for in-flight work.
  • Added ACK and NACK handling.
  • Added retry and delayed retry flows.
  • Added dead-letter behavior for messages that cannot complete successfully.
  • Established shared queues as a substantial second personality alongside durable streams.

Looking Ahead

The next goal for Message Broker was to surround the data plane with operational, security, diagnostic, CLI, and SDK surfaces so teams could evaluate and troubleshoot the broker more realistically.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

ObjectDB 0.5: Runtime Contract and Testability

ObjectDB 0.5 established bounded runtime behavior, compatibility notes, smoke tests, examples, and deterministic unsupported-feature handling.

ObjectDB 0.5 established a bounded operational and runtime contract for ObjectDB.

Added

  • Added documented concurrency, request, header, and payload limits.
  • Added slow-client handling behavior.
  • Added compatibility matrices for supported and unsupported workflow areas.
  • Added operator smoke tests for repeatable validation.
  • Added SDK examples for common client integration paths.
  • Added explicit unsupported-feature behavior so out-of-profile requests fail predictably.

Looking Ahead

The next goal for ObjectDB was to connect the service, compatibility profile, examples, and limits into a coherent private-beta evaluation path for customers.

Notes

This entry records the point where ObjectDB became testable and bounded, not merely functional. Current product status and limits remain documented in the product docs.

Message Broker 0.3: Replay and Consumer Coordination

Message Broker 0.3 added replay, consumer groups, and cursor coordination, making the product a temporal event store.

Message Broker 0.3 added replay and consumer coordination, moving the product beyond a simple message pipe.

Added

  • Added record replay by offset and time.
  • Added consumer group support.
  • Added cursors for coordinated consumer progress.
  • Added cursor inspection, commit, and rewind behavior.
  • Established the product direction as a temporal event store, not only a transient message path.

Looking Ahead

The next goal for Message Broker was to add work-queue behavior alongside streams, including durable delivery state, claiming, retries, and dead-letter handling.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

LogDB 0.5: Tenant and Resource Controls

LogDB 0.5 established multi-tenant admission, dataset authorization, quotas, backpressure, budgets, pagination limits, and related isolation controls.

LogDB 0.5 established multi-tenant admission and resource controls around the LogDB data path.

Added

  • Added tenant credentials and tenant matching behavior.
  • Added dataset authorization controls.
  • Added quotas and backpressure behavior.
  • Added request, record, and byte budgets.
  • Added pagination limits and related isolation mechanisms.
  • Established a clearer boundary for tenant-aware evaluation.

Looking Ahead

The next goal for LogDB was to build the foundation for portable storage and replay, including configured S3 reads, BYOC preflight artifacts, and replay coordination primitives.

Notes

This entry records an isolation and control milestone. External security posture remains review-bound, and current product status and limits remain documented in the product docs.

Message Broker 0.2: Durable Stream Engine

Message Broker 0.2 established the durable stream engine, including stream creation, publish acknowledgement, persistence, and retrieval.

Message Broker 0.2 established the first durable stream-engine milestone for the product.

Added

  • Added stream creation through the native broker API.
  • Added record publishing with durable acknowledgement semantics.
  • Added persisted record storage and retrieval through the broker API.
  • Established the basic "we have a broker" product foundation.

Looking Ahead

The next goal for Message Broker was to move beyond basic publish and retrieve behavior into replay, cursor movement, and consumer coordination so events could be treated as temporal data.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

ObjectDB 0.4: Expanded S3 Workflows

ObjectDB 0.4 expanded beyond basic object PUT and GET into practical S3 client workflows.

ObjectDB 0.4 expanded ObjectDB beyond basic object PUT and GET behavior into practical S3 client workflows.

Added

  • Added multipart upload behavior for larger object workflows.
  • Added support surfaces for object tags and user metadata.
  • Added CORS and bucket policy handling.
  • Added SSE-related request handling.
  • Added SigV4 and presigned request handling.
  • Added delegated browser POST upload behavior.

Looking Ahead

The next goal for ObjectDB was to make the growing service surface easier to test, operate, and reason about by defining runtime limits, compatibility matrices, smoke tests, examples, and unsupported-feature behavior.

Notes

These capabilities were implemented to varying degrees as part of the experimental release line. Current product status, compatibility, and limits remain documented in the product docs.

LogDB 0.2: Telemetry Ingestion Pipeline

LogDB 0.2 established the telemetry ingestion pipeline for logs and traces, including OTLP paths, endpoint helpers, tenant-aware admission, and deterministic record IDs.

LogDB 0.2 established the telemetry ingestion pipeline for the product.

Added

  • Added native OTLP HTTP/protobuf ingestion.
  • Added OTLP JSON compatibility.
  • Added custom endpoint helpers for product-specific ingest paths.
  • Added optional OTLP/gRPC ingestion.
  • Added tenant-aware admission behavior.
  • Added deterministic record IDs for accepted telemetry records.

Looking Ahead

The next goal for LogDB was to move beyond ingestion into a durable storage architecture that could preserve telemetry data with explicit bundle, index, retention, and encryption metadata.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

LogDB 0.1: Initial Experimental Version

LogDB 0.1 established the initial experimental foundation for telemetry ingest, retention, and query workflows.

LogDB 0.1 was the initial experimental version of the Stornamics telemetry and query product.

Added

  • Established the first experimental release line for LogDB.
  • Introduced the product direction for ingesting operational logs and traces, retaining records, and querying data close to the systems that produce it.
  • Set the baseline for later work around durable segment storage, replay, publication, and controlled operational rollout.

Looking Ahead

The long-term goal for LogDB is to give teams a practical telemetry data layer for logs and traces that can run across cloud, on-premise, and hybrid environments with clear retention, query, replication, and operational boundaries.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

LogDB 0.4: Queryable Database

LogDB 0.4 completed the fundamental ingest, persist, and query loop with retained-segment search through POST /v1/query.

LogDB 0.4 made LogDB a queryable database for retained telemetry records.

Added

  • Added POST /v1/query for retained segment search.
  • Added query filtering by dataset.
  • Added exact record ID and exact trace ID lookup.
  • Added time-range query support.
  • Added pagination and deadline behavior.
  • Completed the fundamental ingest, persist, and query loop.

Looking Ahead

The next goal for LogDB was to define stronger tenant, authorization, quota, backpressure, and resource-control behavior around the queryable data path.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

Message Broker 0.1: Initial Experimental Version

Message Broker 0.1 established the initial experimental foundation for streams, queues, replay, and durable event movement.

Message Broker 0.1 was the initial experimental version of the Stornamics streams and queues product.

Added

  • Established the first experimental release line for Message Broker.
  • Introduced the product direction for durable streams, shared queues, replay, cursor movement, and operational event workflows.
  • Set the baseline for later work around replication, diagnostics, auditability, authorization, and controlled broker evaluation.

Looking Ahead

The long-term goal for Message Broker is to help teams move events across cloud, on-premise, and hybrid environments with practical replay, queueing, replication, and operational controls, while keeping delivery and compatibility boundaries explicit.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

ObjectDB 0.3: S3 Core Compatibility

ObjectDB 0.3 established the s3-core-v1 gateway as a defined interoperability contract.

ObjectDB 0.3 established S3 Core compatibility as a named, bounded interoperability target.

Added

  • Added the s3-core-v1 gateway as a defined compatibility contract.
  • Added S3-shaped bucket operations and ListObjectsV2 behavior.
  • Added batch delete, object CRUD, and object copy behavior through the gateway.
  • Added explicit S3-shaped errors for unsupported functionality so clients receive deterministic responses outside the supported profile.

Looking Ahead

The next goal for ObjectDB was to expand from core object-store interoperability into real-world S3 client workflows such as multipart uploads, metadata, browser uploads, request signing, and bucket-level controls.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

ObjectDB 0.2: Functioning Object Store

ObjectDB 0.2 moved the product from architecture and prototype work into a functioning object-store service.

ObjectDB 0.2 was the point where ObjectDB became a functioning object-store service rather than only an architecture or prototype.

Added

  • Added a real service surface with health and readiness behavior.
  • Added bucket lifecycle operations for creating, inspecting, and managing buckets.
  • Added object PUT, GET, HEAD, and DELETE behavior.
  • Added object listing and copy behavior so basic object-store workflows could run end to end.

Looking Ahead

The next goal for ObjectDB was to turn the functioning service into a defined interoperability surface, with S3-shaped behavior, explicit compatibility boundaries, and predictable client behavior.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

LogDB 0.3: Durable Storage Architecture

LogDB 0.3 established the durable storage architecture with WAL-backed flow into the Segment Bundle v1 model.

LogDB 0.3 established LogDB's durable storage architecture.

Added

  • Added WAL-backed data flow for accepted telemetry records.
  • Added publication into the Segment Bundle v1 model.
  • Added Parquet data storage for segment bundles.
  • Added statistics and exact-identifier indexes.
  • Added retention metadata and encryption metadata.
  • Moved the product beyond an ingest API backed by an ad-hoc store.

Looking Ahead

The next goal for LogDB was to complete the fundamental ingest, persist, and query loop by making retained segment data searchable through a defined query API.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.

ObjectDB 0.1: Initial Experimental Version

ObjectDB 0.1 established the initial experimental foundation for object workflows and placement-aware replication.

ObjectDB 0.1 was the initial experimental version of the Stornamics object storage product.

Added

  • Established the first experimental release line for ObjectDB.
  • Introduced the product direction for bucket and object workflows that can run close to the applications and teams that need them.
  • Set the baseline for later work around scoped S3 Core compatibility, object placement, replication, durability checks, and operational limits.

Looking Ahead

The long-term goal for ObjectDB is to help teams keep object data portable and operationally clear across cloud, on-premise, and hybrid environments, with explicit control over where data lives, how it replicates, and which compatibility boundaries apply.

Notes

This entry records early product history and does not represent current availability, support scope, or production readiness. Current product status and limits remain documented in the product docs.