cloudparts

IceGateExperimental

A 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.

What it is
Observability
Used for
Logs,Distributed tracing
Type
Open source
Made by
TripleCloud
License
Apache 2.0
Status
Experimental. The README labels it a prototype; v0.1.0 shipped in April 2026 and v0.2.0 was at release candidate 12 in October 2026.
Facts checked
23 October 2026
Website Source code

What it is

IceGate keeps all of its state in an S3-compatible bucket and runs stateless processes next to it. The ingest service accepts OTLP over gRPC (port 4317) and HTTP (4318) and acknowledges a batch only after it has been written to a write-ahead log, which is itself a set of Parquet files in the bucket. Background workers then batch WAL files into larger Parquet files and commit them to four Iceberg tables, logs, spans, events and metrics, partitioned by tenant, account and day. Workers coordinate through S3 conditional writes (compare-and-swap on objects), and the default Iceberg catalog is a single root.json object in the bucket, so no Kafka, database or catalog service is required; Nessie (REST), AWS Glue and S3 Tables can be used instead.

The query service, built on Apache DataFusion and Arrow, reads the Iceberg tables together with the not-yet-committed WAL, so fresh data is visible at once. It serves a Loki-compatible API for LogQL (port 3100), a Tempo-compatible API with TraceQL search for traces (3200), and a read-only Arrow Flight SQL endpoint (8815) for SQL from Python, JDBC or ODBC clients. A Prometheus-compatible API is planned but every route currently returns 501, so metrics can be stored but not yet queried with PromQL. A maintain service compacts data and manifests, applies TTLs and removes orphan files, and an alert service evaluates rules. Because the tables are plain Iceberg, Trino, Spark or DuckDB can also read them. TripleCloud, which builds it, runs it under its own LLM observability product.

Why teams pick it

  • Object storage is the only stateful component: the WAL, the catalog and the data all live in the bucket, so ingest and query nodes can be added or replaced freely
  • Existing Grafana dashboards and LogQL queries can point at it in place of Loki, and Tempo trace search works the same way
  • Data is standard Iceberg and Parquet, readable by any Iceberg engine without exporting it
  • Apache 2.0 with no paid edition

Watch out for

  • A prototype: no 1.0 release, frequent release candidates, and APIs and storage layout may still change
  • No PromQL yet: the Prometheus API returns 501, so metric dashboards need LogQL or SQL instead
  • Every write and commit is an S3 request; in the authors’ own test, S3 API requests were most of the ingest cost
  • A small project from one company, with a few contributors and few outside users so far

Alternatives

What all observability have in common →Compare side by side →
Grafana TempoOpen sourceA tracing backend that keeps every span as Parquet files in object storage, with no database to run, and finds traces by trace ID or with TraceQL.ParseableOpen sourceA Rust server that stores logs, metrics and traces as Parquet files on object storage and queries them with SQL, without indexing at ingest.

How it fits with other technologies

What IceGate uses

SQL over the merged WAL and Iceberg view through Arrow Flight SQL · python

# pip install adbc-driver-flightsql adbc-driver-manager
import adbc_driver_flightsql.dbapi

conn = adbc_driver_flightsql.dbapi.connect(
    "grpc://localhost:8815",
    # the tenant comes from the x-scope-orgid header, as with Loki and Tempo
    db_kwargs={"adbc.flight.sql.rpc.call_header.x-scope-orgid": "demo"},
)
with conn.cursor() as cur:
    cur.execute("SELECT count(*) FROM iceberg.icegate.logs")
    print(cur.fetchall())

See it in a real stack

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

IceGate comes from TripleCloud, a company founded by Sergei Prosvirnin and Evgenii Mineev that sells LLM and AI-agent observability. Its repository went up on GitHub in November 2025. In a June 2026 post Prosvirnin wrote that self-hosting observability means operating stateful infrastructure, and that even Loki keeps a write-ahead log on local disk, so the team asked whether the stateful part could be taken out of operations entirely, leaving one binary and S3 as the only persistent layer.

The answer was to put the write-ahead log in S3, acknowledge writes only once they are stored there, and use S3 conditional writes in place of Kafka or a coordination service. In their tests, a Kafka, Flink and OpenTelemetry pipeline cost about $700–800 a month at around 10 MB/s, against about $100 a month for IceGate’s ingest path on one small instance, storage excluded. Release candidates for 0.1.0 began in March 2026, 0.1.0 followed in April, and the 0.2.0 series was still in release candidates in October 2026.

Why it’s built this way

The WAL in S3, not on local disk
A local WAL makes every ingest node stateful and needs replication or careful recovery. Writing the WAL to the bucket and acknowledging only after that write lets any node fail without losing data.
S3 conditional writes instead of Kafka or a database
Compare-and-swap on objects is enough to hand out work and to commit catalog updates, so the system needs no extra stateful service to run and pay for.
Iceberg tables for telemetry
Iceberg gives atomic commits and snapshots on object storage, and its open format lets ordinary query engines read observability data without an export step.
Loki and Tempo APIs on the read side
Teams already have Grafana dashboards, alerts and LogQL queries; speaking the same APIs lets them switch the data source without rewriting them.

Timeline

  1. 2025

    IceGate repository created on GitHub in November

  2. 2026

    v0.1.0 in April, after release candidates from March

  3. 2026

    v0.2.0 release candidates from August to October

Sources6 · facts checked 23 October 2026

Improve this page on GitHub