<p><strong>TLDR:</strong> Jaeger v2.18.0 ships ClickHouse as a trace storage backend with 8.6x compression on 10 million spans and sub-100ms retrieval — a concrete alternative to Elasticsearch for high-throughput tracing. Databricks introduced LTAP at their Data &amp; AI Summit, but skeptics are already calling it a rebranded Lakehouse with a real-time engine bolted on. On the Postgres side, two posts dig into planner GUCs (enable_indexscan, enable_bitmapscan, random_page_cost) as diagnostic tools rather than tuning knobs. Redpanda SQL’s bridge queries solve the tiny-Parquet-file problem by letting Iceberg flush on longer cadences while the topic itself fills the freshness gap.</p>
<hr>
<h2>Jaeger v2.18.0 adds ClickHouse backend: 8.6x compression, 50k spans/sec ingestion</h2>
<p>The Jaeger maintainers shipped ClickHouse as an alpha storage backend in v2.18.0. On a single-node deployment with 10 million spans, it compressed ~6 GiB down to ~722 MiB (8.6x), ingested above 50k spans/sec, and returned trace lookups averaging ~100ms with most search queries under 50ms. The schema sorts by service_name and operation name rather than trace_id, uses ClickHouse Nested columns for typed attributes, and adds materialized views for service/operation lookups — worth studying if you’re designing append-heavy analytical schemas. <a href="https://daily.dev/posts/3DmLHzTXI" target="_blank" rel="noopener nofollow">Read more</a></p>
<h2>Databricks LTAP: new acronym, familiar architecture</h2>
<p>Databricks announced LTAP (Lake Transactional/Analytical Processing) at their Data &amp; AI Summit 2026, claiming it unifies transactions, analytics, streaming, and operational workloads on a single storage layer with no ETL. The skeptical read — shared by at least one analyst — is that LTAP is Lakehouse plus a real-time engine, falling into a ‘Shared Tiering’ category that tools like ClickHouse arguably already occupy. The fundamental tension between 3NF OLTP data models and dimensional OLAP models doesn’t disappear because you give the architecture a new name. <a href="https://daily.dev/feed-by-ids?id=g5FCpwJwC&amp;id=CrytTkPCV" target="_blank" rel="noopener nofollow">Read more</a></p>
<h2>PostgreSQL planner GUCs as diagnostic tools: enable_indexscan, enable_bitmapscan, random_page_cost</h2>
<p>Two posts this week make the same core point from different angles: these parameters are probes, not knobs. Toggling enable_indexscan or enable_bitmapscan in a session tells you whether a bitmap or sequential scan would win when an index scan underperforms — the real fix is correcting statistics, work_mem, or random_page_cost. On random_page_cost specifically: no profiling tool can give you the right value automatically because the planner ignores caching effects and working-set size entirely, so it functions as a proxy that nudges the planner toward more cache-friendly access patterns. Tune it by watching pg_stat_statements, not by measuring raw I/O. <a href="https://daily.dev/feed-by-ids?id=ciFAjZmNH&amp;id=h9SOhgWmv" target="_blank" rel="noopener nofollow">Read more</a></p>
<h2>Redpanda bridge queries: Iceberg freshness without tiny Parquet files</h2>
<p>Redpanda SQL’s bridge queries let you query live topic data and historical Iceberg table data through a single virtual SQL table. The practical win is that you no longer need to flush to Iceberg every few seconds to keep analytics fresh — the topic covers the recency gap at query time, so you can flush on a multi-hour cadence and get properly sized, well-compressed Parquet files. That eliminates the compaction service and cuts S3 costs from the thousands-of-tiny-files problem that plagues aggressive flush configurations. <a href="https://daily.dev/posts/4zPKqXtTX" target="_blank" rel="noopener nofollow">Read more</a></p>
<hr>
<h2>Also notable</h2>
<ul>
<li><strong>MongoDB aggregation pipeline redesign: 11.8 seconds to 14 milliseconds:</strong> A field case study shows an RDBMS-style MongoDB data model producing 11.8-second query times on a video streaming service; a pipeline and schema redesign cut that to 14ms — an 800x improvement detailed across a 10-stage aggregation (part 1 of a series). <a href="https://daily.dev/posts/gzqyBWhPz" target="_blank" rel="noopener nofollow">Read more</a></li>
<li><strong>pg_clickhouse v0.3.2: PostgreSQL 19 Beta1 support and TLS options:</strong> pg_clickhouse v0.3.2 adds PostgreSQL 19 Beta1 compatibility, TLS connection options (secure, min_tls_version) for CREATE SERVER, regex flag pushdown fixes, and memory fixes for unbuffered HTTP queries — no restart required. <a href="https://daily.dev/posts/bsqViVpR0" target="_blank" rel="noopener nofollow">Read more</a></li>
<li><strong>Google embeds proxy models in Spanner/AlloyDB/BigQuery at 400x lower token consumption than full LLMs:</strong> Google is shipping tiny in-database proxy models across Spanner, AlloyDB, and BigQuery that can substitute for full Gemini LLM calls at up to 400x lower token consumption and 30-100x lower latency, alongside AI.IF and other AI functions embedded directly in Google SQL. <a href="https://daily.dev/posts/aSXnk5Xfw" target="_blank" rel="noopener nofollow">Read more</a></li>
<li><strong>CYBERTEC releases pg_hardstorage, a new Apache 2.0 PostgreSQL backup tool:</strong> CYBERTEC open-sourced pg_hardstorage (<a href="http://pghardstorage.org" target="_blank" rel="noopener nofollow">pghardstorage.org</a>) as an alternative to pgBackRest, Barman, and WAL-G, targeting Kubernetes and hybrid infrastructure deployment models — architectural details to follow in upcoming technical posts. <a href="https://daily.dev/posts/yYi4MJSuu" target="_blank" rel="noopener nofollow">Read more</a></li>
</ul>


Query optimization, schema design, and data store coverage across PostgreSQL, MongoDB, Redis, and more.

Databases Digest

A curated roundup of database and observability news: Jaeger v2.18.0 ships ClickHouse as an alpha trace storage backend achieving 8.6x compression and 50k spans/sec ingestion. Databricks introduces LTAP at their Data & AI Summit, though analysts see it as a rebranded Lakehouse with a real-time engine. Two PostgreSQL posts clarify that planner GUCs like enable_indexscan and random_page_cost are diagnostic probes, not tuning knobs. Redpanda SQL bridge queries solve the tiny-Parquet-file problem by letting Iceberg flush on longer cadences while live topic data fills the freshness gap. Also covered: an 800x MongoDB aggregation pipeline speedup, pg_clickhouse v0.3.2 with PostgreSQL 19 support, Google's in-database proxy models for Spanner/AlloyDB/BigQuery, and CYBERTEC's new open-source PostgreSQL backup tool pg_hardstorage.

Jaeger gets ClickHouse storage, Databricks coins LTAP