PlanetScale Adds Full-Text Search to Postgres with TIN
PlanetScale released TIN, a full-text search extension for Postgres, on September 16, 2026. It is generally available for all Postgres and Neki databases. PlanetScale describes it as a fast, full-featured, reliable full-text search extension for Postgres. PlanetScale
What TIN does
TIN stands for "Text INdex." It supports boolean expressions, which combine terms with AND, OR and NOT, phrase queries for exact word sequences, and span queries for words in a particular order or distance. For single terms, it supports fuzzy matching for misspellings, wildcard matching for word fragments, and regular-expression matching for defined patterns, with case and accent folding that treats uppercase, lowercase and accented characters as equivalents.
The company documented the release in a blog post titled "Introducing TIN: full-text search for Postgres" and listed a changelog entry titled "TIN: Postgres full-text search" dated September 16, 2026.
What Lead adds
On September 17, 2026, PlanetScale introduced Lead, a TIN-compatible full-text search extension for CI. Lead carries the same feature set and SQL statements as TIN. It is a non-production Postgres text-search extension for exercising TIN-compatible application SQL in development, test and CI. PlanetScale Lead repository Parity is the point.
Lead was documented in a blog post titled "Introducing Lead: TIN-compatible full-text search for CI" and a changelog entry titled "Lead: run full-text search queries in your CI" dated September 17, 2026.
Why it matters for Postgres teams
The broader context here is teams running Postgres in production and the value of keeping search close to the row store, where live records sit. External search clusters solve relevance and scale, but they introduce sync lag, dual writes and a second system to operate, secure and upgrade. An in-database extension with boolean logic, phrase and span operators, plus fuzzy and pattern matching, lets developers express product search, filtering and ranking without leaving transactional SQL. The name is literal. An index that understands text avoids exporting text to understand it.
In my view, the Lead companion matters as much as TIN itself. Full-text behavior is sensitive to tokenization, the rules for splitting text into searchable words, folding rules and query dialect. Tests that pass against a stub can fail against the real index, or pass while relevance drifts. Offering identical SQL and feature coverage for development, test and CI narrows that gap. It allows migration scripts, application queries and ranking assumptions to be exercised on every commit rather than discovered after deploy. Worth flagging for operators, non-production means exactly that, and CI parity does not remove the need for load, relevance and failure testing against production-sized data.
Looking further ahead, the appeal is workflow simplicity. One query language, one data copy for functional tests, and fewer moving parts between laptop and production. If the extension holds up under concurrency and data growth, it gives small teams search without a search team, and gives larger teams a cleaner path to prototype before scaling out. That is a modest, useful kind of progress.
