ParadeDB Search Performance Improvements
craigkerstiens
62 points
10 comments
October 01, 2026
Related Discussions
Found 5 related stories in 89.9ms across 8,245 title embeddings via pgvector HNSW
- Tin: full-text search for Postgres ksec · 206 pts · September 19, 2026 · 54% similar
- Show HN: ParqDB – Vector search in the browser from Parquet over HTTP" petrizhang · 11 pts · August 21, 2026 · 53% similar
- Tin: A Text INdex for Postgres zombodb · 15 pts · September 16, 2026 · 48% similar
- A Preview of DuckDB v2.0 ibotty · 588 pts · August 17, 2026 · 46% similar
- Fast drilldown dashboards from a single Parquet file v3gas · 157 pts · August 24, 2026 · 45% similar
Discussion Highlights (5 comments)
tschellenbach
Definitely looking at using them, you do wonder if such narrow focus is defensible as a business? Probably not.
jamesgresql
ParadeDB'er here: We are really hoping this can turn into a back and forth, making both of our products better.
peterpanhead
ParadeDB kicks the TIN can should be the title.
meerita
Massive respect for ParadeDB for seeing a benchmark where they were 8x slower, taking it as an engineering challenge instead of making excuses, profiling the hell out of it, fixing the actual bottlenecks, and publishing everything they learned along the way. This is what healthy engineering competition looks like.
bomewish
Love to see this. Am a huge paradedb user (we running over 100m records in prod, index is 4tb or so) and I just loved this read.