By PlanetScale shipped TIN (Text INdex) on September 16 — a full-text search extension for Postgres that reaches general availability immediately. If you have been maintaining a Postgres-to-Elasticsearch sync pipeline, this is the release you have been waiting for. TIN runs inside your Postgres transaction, supports BM25 ranking and proximity queries via the TINQL query language, and benchmarks at 25x faster than ParadeDB and 541x faster than built-in GIN indexes. The sync layer is not a design requirement. It is technical debt.
What TIN Actually Is
TIN is a Postgres access method — the same extension mechanism that powers GIN and BRIN indexes. You install it once, create an index on a text column, and search using the ==> operator. Search results obey Postgres MVCC transaction visibility. A row you insert in a transaction is searchable as soon as that transaction commits. There is no pipeline to maintain, no sync delay, and no deleted rows surfacing in search results hours after deletion.
That last point deserves emphasis. Every team that has run an external search service alongside Postgres has dealt with the desync problem: you delete a record, the user refreshes search, the deleted record is still there. TIN makes that impossible by design. Your full-text search index is a Postgres index. It lives where your data lives.
The TINQL Query Language
TIN introduces TINQL, a query language built on top of SQL’s familiar WHERE clause. The ==> operator is a real Postgres operator — it participates in query plans, works with joins, and composes with ordinary WHERE conditions. Here is a complete example:
-- Enable the extension
CREATE EXTENSION tin;
-- Index a text column
CREATE INDEX idx_posts_body ON posts USING tin(body);
-- Search with BM25 ranking
SELECT id, title, tin.score() AS score
FROM posts
WHERE body ==> 'postgresql full text search'
ORDER BY score DESC
LIMIT 10;Beyond basic keyword search, TINQL supports boolean operators (AND, OR, NOT — uppercase required), quoted phrases ("full text search"), fuzzy matching (postgres~2 for edit distance 2), wildcard prefixes, and proximity queries (NEAR(postgresql search, 5)). Result highlighting comes included via tin.highlight(). This is not tsvector with a nicer interface. It is a different class of tool built by engineers who previously built BM25 infrastructure at Elastic.
Lead: The Open-Source CI Companion
The developer community immediately asked how to test TIN queries locally without a PlanetScale account. PlanetScale shipped the answer one day later: Lead, an AGPL-licensed, open-source extension that accepts TIN-compatible SQL and produces correct results without a production search index. You can install Lead on any Postgres instance — local, Docker, or CI.
Lead is intentionally slow. Every scan checks all heap pages, then Postgres rechecks for exact TINQL and MVCC visibility. That makes it wrong for production and exactly right for CI. Write your TINQL queries with Lead locally, run your test suite, then deploy the same SQL to TIN in production without changing a line. No adapter layer, no query translation, no production surprises that were invisible in CI.
Benchmark Numbers
PlanetScale benchmarked TIN on the Hacker News corpus — a live demo runs the full search at github.com/planetscale/hn-search. The results:
- vs GIN: 541x more queries per second; p99 latency 1,356x lower; 50.7 GB indexed in 8 minutes 10 seconds
- vs ParadeDB: 25x more QPS; p99 latency 26x lower; index build 2.4x faster
ParadeDB is a well-funded, Tantivy-based Postgres search extension with real production adoption. TIN being 25x faster on a realistic workload is not a rounding error — it reflects a fundamentally different index design that skips the document-ID-to-ctid mapping layer that other systems require.
What TIN Does Not Do
TIN is not self-hostable today. It runs on PlanetScale’s Postgres and Neki products; Lead is open-source but intentionally non-production. If you self-host Postgres, your current options are ParadeDB, built-in GIN, or an external service — TIN is not available to you yet.
TIN also does not handle vector similarity search. If your application does hybrid search — keywords plus embeddings — you still need pgvector for that dimension. TIN and pgvector can coexist on the same table, so this is a composability concern, not a blocker.
The Verdict
If you are on PlanetScale Postgres and running Elasticsearch or OpenSearch alongside it, the math changed on September 16. The sync pipeline adds operational surface area, introduces sync lag, creates failure modes, and duplicates your storage costs. TIN removes all of that. The query language is mature, the performance numbers are credible, and the Lead companion closes the CI testing gap.
If you self-host Postgres, TIN is not for you yet — but watch the Lead repository. It is AGPL, actively maintained, and a plausible foundation for a future self-hosted implementation. The demand is clearly there. PlanetScale just proved it.
