PlanetScale released TIN, a new Postgres full-text search extension, and Lead, an open dev-only companion

Eric Ridge and Patrick Reynolds at PlanetScale published TIN on 16 September, a new full-text search extension for Postgres. TIN stands for "Text INdex" and reached the front page of Hacker News this morning with 172 points. It is generally available on the day of the announcement for every Postgres and Neki database on PlanetScale, and a companion project, planetscale/lead, is on GitHub under AGPL-3.0 for local development.

What ships

TIN is a Postgres index type. A developer creates it with CREATE INDEX ... USING tin(column) and queries it with a new ==> operator. PlanetScale writes that TIN handles boolean expressions, phrase and span queries, fuzzy, wildcard and regular-expression term matching, case and accent folding, exact COUNT(*), and BM25-ranked top-k queries, and does all of that while respecting joins, complicated WHERE clauses, replication, backups and transaction visibility. The company writes that no existing Postgres text index meets that whole list.

Lead is a separate repository. PlanetScale describes it as "a deliberately non-production Postgres text-search extension for exercising TIN-compatible application SQL in development, test, CI, and staging environments." So a team that pays for TIN in production can install Lead on a laptop or CI runner and run the same queries there.

PlanetScale's own numbers

The benchmarks are the company's own, on an AWS i7i.8xlarge with a Postgres 18.6 container limited to 8 vCPUs and 32 GB of RAM. PlanetScale ran a synthetic query set of 1,719 conjunction, disjunction and phrase queries over an 85 GB Stack Exchange corpus of 150 million documents. It compared TIN v1.0.2 to ParadeDB v0.25.2, pg_textsearch v1.4.0, and Postgres' built-in GIN.

On mixed top-10 ranked queries with no concurrent writes, PlanetScale reports 199 queries per second on TIN against 7.9 on ParadeDB, and a p99 latency of 256 ms against 6,765 ms. On top-10 conjunction and phrase queries against Postgres GIN, the company reports 242 QPS versus 0.4. On disjunction queries with a concurrent client running 1,000 UPDATE statements per second, PlanetScale reports TIN completing 270,279 updates over a ten-minute run against 185,584 for ParadeDB and 735 for pg_textsearch, while still serving 125 QPS with p99 354 ms. GIN could not finish the disjunction workload inside 32 GB.

Index build time on the Stack Exchange corpus was 8m10s for TIN, 19m20s for ParadeDB, 26m49s for pg_textsearch, and 2h09m04s for GIN, each with the RAM the engine needed to build without running out.

Why the architecture allows those numbers

PlanetScale explains that TIN uses the Postgres ctid value directly as a document identifier, rather than assigning sequential IDs and mapping back at query time. A ctid is a 48-bit number that gives the exact heap page and slot for a row, so intersecting and unioning postings lists lines up with vectorized operations on an AVX-512 CPU. ParadeDB and pg_textsearch each keep a separate data structure to translate their internal document IDs back to ctids, which is where the company points for the slower results.

For a team that already runs Postgres and has been keeping an Elasticsearch cluster or Meilisearch service alongside it for search, this is a route to move search back into the primary database, keep transactional consistency, and run the same SQL locally without the managed extension. It is a paid product on PlanetScale, and any switch from an existing search service should be verified against the team's own corpus and workload before it goes to production.

Source

• Primary: PlanetScale, "Introducing TIN: full-text search for Postgres" (16 September 2026)
• Companion project: planetscale/lead on GitHub (AGPL-3.0)
• Discussion: Hacker News thread