PlanetScale's TIN v1.0.6 adds stemming and beats ParadeDB on top-k search again
PlanetScale's Postgres full-text index gets Snowball stemming for 18 languages and block-max tiebreakers, plus a benchmark rematch on 150M Stack Exchange documents.
Why it matters · If you run search inside Postgres instead of a separate engine, this is a vendor benchmark with full details on its setup. It also shows the scoring shortcuts that make up a large share of the speed gap.
Three weeks after launching TIN, its full-text search index for Postgres, PlanetScale has shipped v1.0.4 and v1.0.6. The releases answer customer requests and a ParadeDB benchmark that showed ParadeDB 0.26 beating TIN on read-only, BM25-ranked top-10 queries.
What changed
Stemming maps word variants to one stem, so "runs" also matches "running". Stems aren't always real words: the stem of "database" is "databas". TIN uses the rust_stemmers crate, which runs Snowball algorithms for 18 languages, including Arabic, Russian, Tamil and Turkish. Stemming changes what goes into the index, so you have to rebuild existing indexes (WITH (stemmer = 'en')) after updating to at least v1.0.4.
Tiebreakers. A query like ORDER BY tin.score(ctid) DESC, created_at DESC, id used to score every matching document. Now it uses the same block-max top-k plan as a score-only sort. The post credits TIN's on-disk format and SIMD for the general top-k speedups but doesn't explain them.
The benchmark
The setup is the same as ParadeDB's: 85 GB of Stack Exchange data (150M documents) and 1,254 queries, each run as a conjunction, a disjunction and a phrase query. The server ran in a CPU-pinned 8-vCPU, 64 GB container on an i7i.8xlarge (Xeon), with an i8g (Graviton4) for ARM. Data was read-only and freshly vacuumed, which Reynolds calls a best case. The index was about twice the size of the 24 GB shared_buffers.
One caveat: by default, TIN's scores ignore terms that appear in more than 10% of documents. The terms still count for matching. TIN_FULL scores every term and is the fairer comparison. On the mixed workload on x86:





