QuestDB

We ship a lot of features, examples, and documentation updates in #QuestDB, and it is not always easy to keep track of everything just from release notes or commits. So we added a new docs changelog page. It gives you a simpler way to follow what is new across the documentation, including feature additions, updated examples, guides, and other changes as they land. Useful if you want to keep up with QuestDB developments without having to dig through release history or source code. Link in first comment 👇

WINDOW JOIN in #QuestDB is not just syntactic sugar. Without a dedicated operator, this class of query often turns into a fairly ugly combination of ASOF JOIN, range joins, UNION ALL, and GROUP BY, making efficient execution difficult. We published a deep dive into how QuestDB executes WINDOW JOIN internally: * partitioning work across workers * vectorized/SIMD aggregation * reusing aggregation kernels from SAMPLE BY * optimizing contiguous window slices for low-cardinality joins The article also compares the resulting execution path with equivalent approaches in Timescale, DuckDB, and ClickHouse. On the benchmarked workload, the new execution path was 5x faster than the previous QuestDB implementation. Link in first comment 👇

One of the interesting aspects of designing your own ingestion protocol is that you get to decide exactly what matters most. In this example from the upcoming QWP protocol in #QuestDB, you can see several optimizations working together in the same message format: • Multi-table ingestion • Schema evolution support • Gorilla delta-of-delta encoding for timestamps • Symbol dictionary compression • Compact binary columnar layout The goal is not just reducing payload size, but minimizing overhead across the full ingestion path while keeping decoding efficient on the server side.

We are adding more SQL window functions to #QuestDB: • ntile(n) distributes rows of an ordered partition into approximately equal buckets • cume_dist() returns the cumulative distribution of the current row within the partition • nth_value(value, n) returns the n-th value within the current window frame These functions are commonly used for ranking, bucketing, percentile-style analysis, and distribution analysis directly in SQL. Typical use cases include: * splitting instruments or users into quantiles * identifying top and bottom segments * cumulative ranking analysis * retrieving specific values within analytical windows They fit naturally alongside existing time-series and analytical windowing workflows in QuestDB.

For years, we’ve said that most #QuestDB workloads do not need indexes. That is still true for the majority of time-series queries, where sequential scans over ordered columnar data are often faster and simpler than maintaining large indexing structures. But there are also workloads that combine time filters with highly selective predicates, for example filtering a narrow set of symbols while reading only a few additional columns. We are now adding covering indexes in QuestDB for these query shapes. If all required columns are already present in the index, the engine can answer the query directly from it without reading the underlying table data. Stay tuned!

We are extending SAMPLE BY FILL in #QuestDB with cross-column PREV() support. Previously, a filled column could only carry forward its own previous value. Now it can inherit the previous value from another aggregate. That turns out to be very useful for OHLC generation. On empty buckets, the candle open can inherit the previous close directly in SQL, instead of carrying forward the previous open. We are also moving supported SAMPLE BY FILL queries from the sequential cursor path onto the parallel GROUP BY execution path.

Last week we mentioned that OHLC bars are coming to #QuestDB. We’ve now written more about the broader idea: rendering small charts directly in SQL results as text. That includes sparklines, candlesticks, and also market depth charts, which are particularly useful when working with order book data and liquidity analysis. The goal is simple: when you are already querying data, you can quickly get a visual sense of what is going on without switching tools. Link in first comment 👇

What if your query could return OHLC bars directly? We’re working on rendering OHLC bars as part of SQL results in #QuestDB, returned as a VARCHAR alongside your data. Handy when you are already in a query and want to quickly see how price moved or compare trends, without jumping to a chart. Coming soon.

One nice aspect of storage policies in #QuestDB Enterprise is that storage tiers are not mutually exclusive. Data can live in the native columnar format for fast ingestion and low-latency queries, while also being available in Parquet for access from external tools. This makes it possible to: • Keep a fast query tier in native format • Expose the same data in Parquet for interoperability • Gradually, and automatically, move away from native storage when it is no longer needed Instead of forcing a transition between formats, you can choose to keep both when it makes sense, and optimise for both performance and openness at the same time.

We’re excited to be nominated for the DBTA Readers’ Choice Awards this year. These awards are driven by the community, and it’s great to see QuestDB included among the technologies people are using and recommending. If #QuestDB has been useful to you, we’d really appreciate your support. Voting is open until May 22. Thanks to everyone building with us and pushing the project forward. Link in first comment 👇