PlanetScale’s TIN extension beat ParadeDB 0.25 by at least 8× in its BM25 benchmarks, crediting an architecture built around PostgreSQL ctid values. ParadeDB profiled the workload and closed—or reversed—the gap in two weeks without changing document identifiers.
The largest gains came from two narrower fixes:
- Tantivy’s one-byte fieldnorm values lived in a global array, turning sequential postings scans into scattered PostgreSQL page reads. Storing fieldnorms beside each term’s postings cut those accesses from roughly 1,500 pages to 30, while growing the index about 9%.
- Blockmax WAND spent too much CPU deciding what to skip on large disjunctions. ParadeDB added MAXSCORE and selects it for sufficiently dense queries with at least three terms, cutting p50 latency about 6× and p95 about 8× on a ten-term test.
The benchmark itself also needed scrutiny:
- Unqualified ParadeDB queries searched two indexed fields while TIN searched one.
- TIN’s default dense-term elision skipped common words, making ranking approximate rather than exact BM25.
- Synthetic queries such as “is it” and “to a” exaggerated that shortcut. With elision enabled, 47.8% of queries had at least one result outside the exact Top 10; for disjunctions, it was 88.2%.
The useful lesson is not which engine won a chart. A benchmark can expose a real problem while supplying the wrong architectural explanation. Measure the hot path first, separate locality costs from algorithmic costs, and make approximation part of the benchmark contract rather than a hidden configuration detail.
ParadeDB’s dense u32 document IDs still have a defensible advantage: they compress well and map directly into columnar data used for filters, facets, and field-based ranking. ctid helps other workloads, especially visibility checks and counting. The choice is a workload trade-off, not a universal hierarchy.