PlanetScale's TIN full-text search extension for Postgres hits GA with big benchmark claims

What TIN is

PlanetScale has announced the general availability of TIN, a full-text search extension for PostgreSQL. The company says full-text search is the feature its customers request most, and TIN — short for "Text INdex" — is its answer. It is available immediately for all Postgres and Neki databases hosted by PlanetScale.

The extension plugs into ordinary SQL. An index is created with CREATE INDEX ... ON table_name USING tin(text_column_name), and queries use a new ==> operator. PlanetScale's examples include an e-commerce search returning the top ten products ranked by tin.score(ctid), a legal-discovery query that must return every matching document without ranking, and an exact COUNT(*) over photo tags.

According to PlanetScale, a serious text index must support Boolean, phrase and span queries; fuzzy, wildcard and regular-expression matching on terms; case and accent folding; and both COUNT(*) and BM25-scored top-k queries — all while coping with joins, WHERE clauses that mix text and non-text predicates, continuous updates, replication, backups and transaction visibility. The company says at least three text-search indexes already exist for Postgres, but none met every requirement.

How PlanetScale benchmarked it

To support the performance claims, PlanetScale tested TIN v1.0.2 against ParadeDB v0.25.2, pg_textsearch v1.4.0 and the GIN index built into Postgres 18.6. The headline corpus was an 85 GB export of Stack Exchange posts — 150 million documents — probed with 1,719 synthetic queries built by sampling substrings of 2 to 15 terms and interpreting each as a conjunction, a disjunction or a phrase. Everything ran on an AWS i7i.8xlarge instance with local NVMe storage and an AVX-512-capable CPU, with each engine inside a container capped at 8 vCPUs and 32 GB of RAM — deliberately small, PlanetScale says, so the index does not simply sit in Postgres buffers. Load came from a forked ParadeDB Benchmarker that pre-warms and tracks bytes read and written. The company also tested against all of Wikipedia, 2.3 TB of Reddit comments and a 797 GB mixed corpus of research papers, legal documents, books and Enron emails.

The numbers PlanetScale reports

For index builds on the Stack Exchange corpus, TIN finished in 8 minutes 10 seconds, producing a 50.7 GB index within the 32 GB memory limit. ParadeDB took 19 minutes 20 seconds for a 52.1 GB index but needed 64 GB; pg_textsearch took 26 minutes 49 seconds for 41.5 GB and needed 128 GB; built-in GIN took 2 hours 9 minutes for a 28 GB index and also needed 64 GB.

On mixed conjunction, disjunction and phrase queries returning the top 10 results by BM25 score, TIN handled 25 times as many queries per second as ParadeDB, with p99 latency 26 times lower. GIN could not finish the workload — it exhausted memory on disjunction queries — and pg_textsearch could not finish it because it only supports disjunctions. On ranked conjunction and phrase queries, TIN handled 10 times the throughput of ParadeDB and 541 times that of GIN, with p99 latencies 6 times and 1,356 times lower respectively. Aside from TIN, only ParadeDB completed every benchmark. PlanetScale also measured a counting workload over an 8.0 GB Wikipedia corpus with the index fully resident in shared buffers.

Reads and writes at the same time

The concurrent-write benchmark ran disjunction queries with top-10 BM25 results while a client targeted 1,000 UPDATE statements per second. TIN sustained 57 times the query throughput of ParadeDB and 36 times that of pg_textsearch, with p99 latencies 36 times and 24 times lower. Over a ten-minute run, TIN completed 270,279 updates, ParadeDB completed 185,584, and pg_textsearch completed 735. PlanetScale attributes that last collapse to lock starvation: constant read traffic prevented writes from acquiring the locks they needed, so writes stalled within seconds. ParadeDB's approach to accepting writes, the company argues, costs it read throughput and latency.

Why it matters

PlanetScale's framing is that its customers ask for this feature more than any other because Postgres's existing options fall short, and the benchmarks are meant to show how far: the built-in GIN path could not even complete two of the workloads. If the numbers hold up outside PlanetScale's lab, transactional search — results visible the moment a row commits, backed up with the database, no external pipeline to keep in sync — becomes practical on modest hardware, since these results come from an 8-vCPU, 32 GB container rather than a large machine.

The caveat is that these are vendor-run benchmarks: PlanetScale picked the corpus, generated the queries and set the tuning parameters, and engines were excluded from workloads they could not run at all. The company does publish enough environment detail — instance type, container limits, Postgres settings — for others to reproduce the setup, and with TIN now generally available on its hosted Postgres, the fastest validation is simply trying it on real data.