Open Source • Apache 2.0

OpenSearch,
without the operations.

The only open source serverless Lucene implementation.

Self-healing, serverless architecture built for petabyte scale. No migrations and No rewrites. OpenTelemetry compatible.

90%
Cost Savings
< 1s
Search Latency
PB
Scale
OpenSearch
API Compatible

Trusted by teams at

Slack Airbnb Salesforce

Why KalDB

Log search without the legacy tradeoffs

Self-hosted

Run in your own AWS, GCP, or Azure account. Logs never leave your VPC.

90% lower TCO

Pay for S3 storage and active compute. No per-GB ingestion fees, no over-provisioned clusters.

Petabyte scale

Scale indexing and query compute independently. Sub-second search across years of retention.

Production-proven

Runs at petabyte scale at Slack and Airbnb. OpenSearch API compatible — drop-in for existing tooling.

KalDBElasticsearchSplunk / Datadog
Compute / storageDecoupled, S3-backedCoupledOpaque SaaS
Pricing modelYour cloud billPer-node licensingPer-GB ingestion
Data sovereigntyIn your VPCSelf-host or managedVendor cloud
LicenseApache 2.0SSPL / ElasticProprietary
APIOpenSearch compatibleNativeProprietary

A Fully Disaggregated Architecture

KalDB pulls every traditional log-search role onto its own tier — preprocessing, indexing, serving, and storage — so each one scales to its own bottleneck and a spike in one can never stall the others.

Preprocessing / Indexing

Clean data before it hits the index

Preprocessors validate records, enforce per-service rate limits, and partition data into Kafka. Indexers consume prepared partitions — nothing else.

Indexing / Serving

Writes never slow down reads

Stateless indexers own the write path. Dedicated query and cache nodes own the read path. An ingest spike cannot back up dashboards, and a heavy query cannot stall Kafka.

Compute / Storage

All durable data lives in S3 and Kafka

Closed Lucene chunks are uploaded to S3; in-flight logs sit durably in Kafka. Every compute tier is stateless — scale up for peak, scale to zero off-peak.

Historical / Long-term

Only the hot window stays on disk

Recent data lives on indexers. Cache nodes hydrate a configurable window from S3 to local disk. Everything older stays cheaply in S3 for long retention, not on hot nodes.

Write Path
1

Preprocessor

HTTP ingest lands on preprocessor nodes that validate records, enforce per-service rate limits, and partition messages into Kafka.

2

Kafka durable buffer

Kafka absorbs ingest spikes so producers and indexers scale independently and no fresh data is lost while chunks are still being built.

3

Stateless indexers

Indexers consume assigned Kafka partitions and build a Lucene index on local disk. The active chunk is open for both reads and writes while fresh logs stream in.

4

Chunks roll to S3

Once a chunk hits its size or offset limit it closes, is uploaded to S3, and its metadata is published so it can be assigned to the cache tier.

5

Recovery backfills lag

If an indexer falls behind, recovery nodes pick up skipped offsets so fresh ingest stays prioritized and historical gaps are filled separately.

Query Path
1

OpenSearch-compatible query nodes

Grafana and other clients hit a stateless query service that speaks the OpenSearch API over HTTP — no client rewrites.

2

Separate hot and historical tiers

Query nodes fan out to live indexers for recent data and to cache nodes for read-only snapshots already in object storage.

3

Cache tier hydrates from S3

Cache nodes download Lucene chunks from S3 to local disk and serve a configurable retention window — not every byte you ever stored.

4

Manager coordinates assignments

The manager tracks snapshots, replicas, cache slot assignments, and retention so each query quickly finds the right chunks to search.

5

Scatter-gather merge

Query nodes merge responses across indexer and cache tiers so users get a single result set even though storage and compute are fully disaggregated.

Talks

Conference presentations on KalDB's architecture and operations

KalDB: A k8s Native Log Search Platform

Monitorama 2022 — Suman Karumuri

KalDB: A Cloud Native Log Search Platform

Strange Loop 2022 — Suman Karumuri

KalDB: Serverless Lucene at Petabyte Scale

Berlin Buzzwords 2023 — Suman Karumuri

Taming Spiky Log Volumes with KalDB

SREcon23 Asia/Pacific — Suman Karumuri

Built For Your Use Case

Proven at scale across industries

Self-Hosted Search

Deploy in your own cloud account with full control. Meet compliance requirements without compromising on features.

  • Data never leaves your VPC
  • SOC2, HIPAA, GDPR ready
  • Full infrastructure control

Observability at Scale

Handle millions of events per second. Correlate logs, metrics, and traces across your entire infrastructure.

  • Sub-second queries at PB scale
  • Grafana & Kibana compatible
  • Real-time alerting

Security Analytics

Detect threats and investigate incidents in real-time. Retain security logs for years at minimal cost.

  • SIEM integration ready
  • Long-term retention at $0.023/GB
  • Forensic investigation

Get Started in Minutes

Self-host KalDB with Docker or run in your cloud

Local Deployment

# Clone and start
git clone https://github.com/kaldb/kaldb
cd kaldb
docker-compose up
✓ Running on localhost:8080
Deploy Now