Tag: databases

Jovan Stojiljkovic runs the comparison that embedded-database conversations often skip: the same observability application, the same inexpensive machine, and disclosed load and read thresholds. For wide scans, aggregations, and telemetry retention, DuckDB's columnar execution moves the practical limit dramatically. The most valuable part is not the headline multiplier; it is the attempt to define a real user-facing read cliff and publish the conditions behind it.

The Hacker News discussion correctly narrows the conclusion. DuckDB is not a generic replacement for SQLite: its strengths are analytical scans and local batch work, while SQLite remains a durable fit for transactional application state and different concurrency needs. Benchmarks should make the workload decision sharper, not turn two distinct engines into a universal winner and loser.

This is a good practical explainer because it connects the usual "add an index" advice to the physical model underneath: pages, tuples, ctid, B-tree roots and leaves, and the way PostgreSQL can avoid dragging a query through the whole table.

The Hacker News thread gets the teaching problem right. This is exactly the kind of PostgreSQL-specific reference you want when someone knows queries are slow but does not yet have a mental model for why missing indexes hurt. The deeper lesson is that performance work gets easier when the database stops being a black box and starts looking like a set of page-level tradeoffs.