PlanetScale ships TIN, a Postgres full-text search index it claims crushes rivals

PlanetScale has released TIN (short for “Text INdex”), a full-text search extension for Postgres, now generally available across its Postgres and Neki databases. Developers create it with a standard CREATE INDEX … USING tin(…) statement and query it through a new ==> match operator, with BM25 relevance scoring via tin.score(). TIN targets the gaps PlanetScale says existing options leave open: it supports boolean, phrase, and span queries; fuzzy, wildcard, and regex term matching; case and accent folding; and both COUNT(*) and top-k ranked queries — all while behaving like a real Postgres index across joins, complex WHERE clauses, concurrent writes, replication, backups, and correct transaction visibility. The company argues that none of the three existing Postgres text indexes (ParadeDB, pg_textsearch, and the built-in GIN) satisfy that full list.

The pitch leans heavily on benchmarks run against an 85 GB Stack Exchange corpus of 150 million documents, executed on an AWS i7i.8xlarge instance with Postgres 18.6 confined to 8 vCPUs and 32 GB of RAM so the index wouldn’t simply live in buffers. The headline numbers are large: TIN reportedly handled 25× the QPS of ParadeDB on mixed top-10 ranked queries, 10× ParadeDB and 541× GIN on conjunction and phrase queries, and 36×/57× the throughput of pg_textsearch and ParadeDB on disjunction queries running alongside 1,000 UPDATEs per second. Notably, GIN and pg_textsearch couldn’t even complete several tests — GIN ran out of memory on disjunctions, and pg_textsearch only handles disjunction top-k queries and stalled under concurrent writes.

The more interesting technical signal is TIN’s low bytes-read-per-query, which PlanetScale credits for both its speed and its lighter footprint on shared I/O and block cache — meaning co-located workloads stay fast. As with any vendor-run benchmark, the results warrant independent verification, but the design goals reflect a genuine, long-standing pain point: Postgres users have wanted first-class full-text search that doesn’t force a separate search engine, and TIN is a bid to keep that workload inside the database.