TIN Beats ParadeDB by 57x in PlanetScale's Own Postgres Test

PlanetScale software engineer Eric Ridge, previously a distinguished engineer at GitHub who co-founded GitHub Actions, and PlanetScale software engineer Patrick Reynolds introduced TIN, a full-text search extension for Postgres, in a company blog post published Sept. 16. Against an 85-gigabyte, 150-million-document Stack Exchange corpus, TIN answered a mixed top-10 query workload at 199 queries per second, versus 7.9 for the rival extension ParadeDB, a 25-fold gap, and a disjunction workload with concurrent writes at 125 queries per second against ParadeDB's 2.2, a 57-fold gap. Both extensions rank results with BM25, a decades-old formula that scores how well a document matches a search query based on how often the query's terms appear in it, weighted against the document's length.

What the numbers actually show

TIN builds its index differently than most Postgres search extensions: instead of assigning each document a sequential ID that has to be mapped back to a database row, it indexes directly against Postgres's own ctid, the 48-bit address that already points at a row's physical location on disk, according to the announcement. PlanetScale says that choice is what lets TIN skip an ID-mapping step other extensions pay for on every query.

Scenario	TIN	ParadeDB
Index build, 150M documents	8m 10s	19m 20s
Mixed queries, top-10	199 QPS	7.9 QPS
Conjunction and phrase, top-10	242 QPS	24 QPS
COUNT(*) on Wikipedia corpus	10,260 QPS	291 QPS

Two other extensions ran into limits before finishing the same test set: Tiger Data's pg_textsearch could only complete the disjunction workload, at 3.5 queries per second against TIN's 125, and Postgres's own built-in GIN index ran out of memory on most of the workloads, managing only 1.4 queries per second on the COUNT query it did finish. PlanetScale ran every benchmark itself, on its own hardware, so the figures are a vendor claim rather than an independently verified result.

The index-build step also shows a tradeoff PlanetScale's headline multipliers do not: TIN's index came out to 50.7 gigabytes at 32 gigabytes of memory used during the build, while ParadeDB's larger 52.1-gigabyte index needed 64 gigabytes of memory, twice TIN's footprint, to build in more than twice the time.

Where "for Postgres" stops being literal

A reader could take "full-text search for Postgres" to mean an extension installable on any Postgres instance with CREATE EXTENSION. PlanetScale's own extensions documentation lists TIN as a "Supported Community Extension," version 0.9.0, available on Postgres 18.6 and 17.11, but only inside PlanetScale's own hosted Postgres and its sharded Neki product. There is no planetscale/tin repository among the 157 repositories in the PlanetScale GitHub organization, and neither the announcement nor the changelog states a license for TIN's own source.

What PlanetScale has published is Lead, an AGPLv3-licensed extension built by the same two engineers that Ridge and Reynolds describe as accepting TIN-compatible SQL for development, test, CI and staging environments while deliberately not matching TIN's production performance. Lead is real, buildable code a developer can run on a laptop. TIN, the extension the benchmark numbers describe, is not.

What an independent reviewer flagged

RuntimeWire's coverage of the launch, published the same day as PlanetScale's changelog entry, wrote that the benchmark figures "come from PlanetScale's own test design, synthetic query set and isolated hardware," and that developers evaluating TIN "should rerun the work against their own documents, index sizes and query mixes before treating the headline multipliers as purchasing criteria." The outlet drew a comparison to PlanetScale's Sept. 11 benchmark of Neki, its sharded Postgres product, which it said reported 118 million queries per second in a horizontal-scaling test that left out writes, joins, replicas and failover, the operations that tend to determine whether a database holds up in production rather than in a demo. That kind of vendor-run number is not unique to PlanetScale: Vercel's claim that its newer OpenSearch Serverless architecture autoscales 20 times faster for bursty workloads also comes from the vendor's own testing rather than an independent benchmark.

That pattern matters here because a search extension's hardest cases, index rebuilds under live write load, ranking quality on real user queries instead of a Stack Exchange corpus, and behavior during a Postgres major-version upgrade, are exactly the cases a vendor's own single-run benchmark is least likely to expose. Postgres libraries have converged on similar single-vendor demonstrations before, where three independent durable-execution systems built on Postgres each published their own numbers without a shared, neutral test.

What's still unconfirmed

PlanetScale has not said whether TIN will ever ship as an installable extension outside its own product, what pricing tier includes it, or why the company chose to release Lead under AGPLv3, a copyleft license that requires anyone who modifies and redistributes it to publish their own changes, while leaving TIN itself without a public license of any kind. Neki, the sharded Postgres product TIN is built into, is PlanetScale's system for spreading a single logical Postgres database across many physical shards, a capability the company markets against Neon's Lakebase with a self-run TPCC benchmark claiming roughly 18,000 queries per second for PlanetScale against about 12,500 for Neon.

A developer who wants BM25 ranking, phrase queries and TIN's claimed throughput today has exactly one option for getting it into production: running Postgres on PlanetScale. Everyone else gets Lead, a tool its own documentation says is built for correctness rather than speed, or one of the three extensions TIN's own benchmark just finished beating.