HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
xataio
deltax
Rust2026–2026
xataio / deltax

deltax

Fast time-series extension for PostgreSQL

2Distinct people
4Mentions
0Explicit recommenders
293GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Fast time-series extension for PostgreSQL

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week4 dated mentions

Observed mentions: 2026-05-19 18:36:10 UTC to 2026-07-09 09:41:33 UTC. Weeks start Monday, UTC.

012026-05-18 00:00:00 UTC to 2026-05-25 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsMay 182026-05-25 00:00:00 UTC to 2026-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-01 00:00:00 UTC to 2026-06-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-08 00:00:00 UTC to 2026-06-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJun 82026-06-15 00:00:00 UTC to 2026-06-22 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-06-22 00:00:00 UTC to 2026-06-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-29 00:00:00 UTC to 2026-07-06 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-07-06 00:00:00 UTC to 2026-07-13 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJul 6

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
May 182026-05-18 00:00:00 UTC2026-05-25 00:00:00 UTC110
May 252026-05-25 00:00:00 UTC2026-06-01 00:00:00 UTC000
Jun 12026-06-01 00:00:00 UTC2026-06-08 00:00:00 UTC000
Jun 82026-06-08 00:00:00 UTC2026-06-15 00:00:00 UTC000
Jun 152026-06-15 00:00:00 UTC2026-06-22 00:00:00 UTC101
Jun 222026-06-22 00:00:00 UTC2026-06-29 00:00:00 UTC000
Jun 292026-06-29 00:00:00 UTC2026-07-06 00:00:00 UTC101
Jul 62026-07-06 00:00:00 UTC2026-07-13 00:00:00 UTC101

What Hacker News says

4 sources
> - Is ~300x faster than Postgres on analytical workloads. Right now it's 2x slower than Clickhouse on clickbench and I think it's possible to get faster than Clickhouse That sounds like you are storing the data in a columnar format? Or do you do both row and columnar? In a somewhat similar (yet also quite different) effort, I've been working on δx, a Postgres extension that compresses the data in a columnar format stored in normal Postgres tables (so replication, crash recovery, pg_dump, etc. still work normally). https://github.com/xataio/deltax It is currently about 30-40% slower than ClickHouse (single node, ofc). The PR to add it to clickbench was just accepted, so you can see the comparison here: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...
In Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
A bit of a shameless plug, but I've been working on this for a few months in the form of an extension: https://github.com/xataio/deltax When I started I thought there's too much inherent overhead in using Postgres tables for storage and using the Postgres executor, so figured it would be pretty cool to match Timescale in performance. I didn't think it would be possible to get close to dedicated analytical DBs. But as the project progressed and the performance got better and better, I'm now firmly in the camp of doing analytics with Postgres + an extension.
In Looking Ahead to Postgres 19
I have been working on another PG extension for timeseries (https://github.com/xataio/deltax) for a few months, and trying to make it score as good as possible on ClickBench. This is a project that is simply lot of fun to work on. There are many tricks that can be used to speed-up analytics, besides just type-aware compression: * for each segment you will keep things like max/min/sum, number of distinct values, bloom filters, etc. For a good amount of common queries, you can answer them just based on this metadata, so you don't need to decompress the columns at all. * for text column, you compress them differently based on cardinality. Low cardinality (think labels or similar) is dictionary based compression. High cardinality is LZ4. * Generally the smaller the data on disk, the higher the cold runs performance. This is because you need l
Read the rest
ess IO to load it in memory. I have discovered that on top of the type-aware compression, it's worth doing another round of LZ4. There's also some research that it's sometimes worth doing multiple passes of LZ4. * Partition and segment pruning. If you can tell from the metadata or bloom filters that the filter doesn't match a partition or segment, you skip the whole thing. * Push down of filters in the decompression layer. Depending on the compression algorithm, while you decompress you can also filter out the values that you don't need. This avoids passing data and allocating memory for elements that will be later discarded anyway. * Organization of data on disk is more important than almost anything else. Of course, that's the main point of columnar storage, but there are level of details on how to organize the data so that IO is minimized during queries. I have tried 3-4 different layouts before settling on one. * For top N type of queries, which are really common in analytics, you want to stop the reading from disk / decompressed as soon as you have enough data to guarantee that you have a correct top N to satisfy the query. * Parallelize everything: at least ClickBench runs on instances with a lot of CPU cores, so you need to parallelize every step of the way. This is done differently depending on the query type. For example for top N, each worker can take a subset of the segments and get the top N from each of them. Then you combine those in a single result.
In How TimescaleDB compresses time-series data

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.