PlanetScale's TIN searches a Postgres row the moment its transaction commits

A TIN index is created with `CREATE INDEX posts_body_tin ON posts USING tin(body)` and queried with a new operator, `==>` ^[4]. Boolean, phrase and span searches are supported, along with fuzzy terms, wildcards, regular expressions and case and accent folding, and a query can return exact counts or BM25 scores ^[5]. Because the index lives in the database, it is covered by the same replication and backup path as the table it indexes ^[6]. Patrick Reynolds, one of the two contributors credited with the launch, founded GitHub's Blackbird code-search project before joining PlanetScale ^[21].

PlanetScale's documentation says each TIN index covers one text column or expression ^[7]. Ranking a post by title and body therefore means two indexes, combined at query time with per-field boosts, plus partial or expression indexes for narrower cases ^[7]. The default tokenizer folds case and accents and indexes emoji as searchable terms ^[8].

The 1,719 queries in the benchmark were generated from substrings of two to 15 terms taken out of the corpus itself ^[10]. Every query matches something by construction, and query term frequencies follow document term frequencies. Production query logs contain misspellings, terms that are not in the corpus at all, and a head-heavy distribution that warms a cache differently. Only TIN and ParadeDB completed every workload; GIN and pg_textsearch dropped out of some comparisons after running out of memory or failing to support the query shape ^[19].

Converted to seconds, the two extreme build times are 490 and 7,744, a factor of 15.8 ^[1]. At 490 seconds for 150 million documents, that is roughly 306,000 documents indexed per second ^[2]. ParadeDB built a slightly larger index, 52.1 GB, in 19 minutes 20 seconds ^[14]. PlanetScale raised the memory limit for the three competing systems during index construction after they failed at 32 GB, then returned every system to 32 GB for query testing ^[12].

The 50.7 GB index exceeds the 32 GB query-phase cap by 18.7 GB ^[3], so the query phase read from storage on the i7i.8xlarge instance ^[11]. On a box where the index fits in page cache, the ratios come out differently.

In the conjunction-and-phrase workload PlanetScale reported 242 queries per second for TIN, 24 for ParadeDB and 0.4 for GIN ^[18]. Those are read measurements against an index that was already built. PlanetScale did not publish query throughput under sustained ingest, and that is the case that decides whether one system can stand in for two.

Runtimewire's account of the launch describes Lead as a compatible but deliberately slow substitute for local development, CI and staging ^[20]. Relevance and correctness can be checked there, while latency regressions will only show up against a production-grade instance.