Producer & Ingest Stats
What it is
Section titled “What it is”Every byte that enters AetheriusDB — whether it arrived via INSERT, a bulk Arrow
batch, a Kafka source, or a CDC bridge — flows through one instrumented ingest
path. That path keeps live counters for rows accepted, rows materialized,
durability latency, and backpressure events. The catalog also keeps per-table
statistics — row count, last update epoch, and optionally column histograms — that
the query planner reads when deciding how to execute your SQL.
Both signals are exposed through the system catalog as ordinary SQL views. You query them the same way you query your own tables: build dashboards on top, alert on lag, and debug planning decisions by inspecting the exact numbers the planner reads.
Why use it
Section titled “Why use it”Honest observability is the difference between “the system says it’s healthy” and “the system actually is healthy.” A unified ingest surface gives you one place to look when ingest goes wrong, and accurate row counts mean the planner’s cardinality estimates aren’t fiction.
- One counter set — every ingest path reports through the same metrics, so totals add up.
- Live row counts — each table’s
row_countis monotonic and durable across restarts. - Better plans — the planner consumes accurate cardinalities, so estimates match reality.
How to use it
Section titled “How to use it”Read the system catalog. The same SQL you write against your application tables works here — group, filter, and join with your own data.
-- Throughput and lag per table over the live ingest path.SELECT table_name, rows_per_sec, backpressure_events, last_durable_at FROM aether.ingest_stats WHERE table_name IN ('orders', 'telemetry');
-- Catalog row counts that the planner uses.SELECT table_name, row_count, last_updated_epoch FROM aether.table_stats ORDER BY row_count DESC LIMIT 10;
-- See estimated vs actual cardinalities for a query.EXPLAIN ANALYZE SELECT region, COUNT(*) FROM orders GROUP BY region;EXPLAIN ANALYZE annotates every operator with both the estimated rows (from
catalog statistics) and the actual rows seen at execution — the same signal the
adaptive planner uses to decide when to replan mid-flight.