Shredding JSON columns gave Logfire up to 1000x faster queries
acossta
16 points
9 comments
October 11, 2026
Related Discussions
Found 5 related stories in 216.6ms across 9,162 title embeddings via pgvector HNSW
- The Lifecycle of a Sharded Postgres Query sarokhan · 14 pts · September 10, 2026 · 46% similar
- Why Elasticsearch is becoming a columnar database shivanshuag · 14 pts · August 21, 2026 · 45% similar
- Show HN: Pivot – fast analytics on Iceberg, 2x+ faster than ClickHouse / DuckDB dkgs · 11 pts · October 08, 2026 · 45% similar
- pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries saisrirampur · 49 pts · August 11, 2026 · 44% similar
- LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacB Alephinitesimal · 15 pts · August 21, 2026 · 42% similar
Discussion Highlights (5 comments)
sans_souse
Let's just revert back 30 years and make the entire www plain text. What could possibly go wrong?
sgarland
It is hilarious to me when companies act like they've made some huge discovery that's been well-known to anyone working in DBs for the past decade, if not more. JSON is slow as hell, both for serdes, and especially querying it. Use it sparingly, if at all. Normalization is not that hard, and it's trivial now with LLMs. Tell Claude you want your schema in BCNF, or 5NF if you're feeling froggy. Denormalize if and only if you have performance issues.
japgolly
> Rather than storing all attributes in a single JSON column, we automatically extract the most frequently accessed attributes into separate, strongly typed columns. I'm glad they made the discovery but this is DB 101
zX41ZdbW
This is quite an old technique. In ClickHouse, it appeared before it was named "shredding": https://github.com/ClickHouse/ClickHouse/issues/54864
MrThoughtful
Why not store everything in a single json column but dynamically generate index files, so finding rows is fast? Then you never have to change the data. Only the index files.