Your Database Can Now Search Text on Its Own
PlanetScale released TIN, a new way to search text inside Postgres, on September 16, 2026. It is 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." Think of it like the index at the back of a textbook, but built into the database itself.
It can combine words with AND, OR and NOT. It can find exact phrases. It can find words placed in a certain order or distance from each other. It can forgive spelling mistakes, match parts of words, and match set letter patterns. It treats capital and small letters as the same, and does the same for accented letters.
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 keeping search where the data already lives. Separate search systems can handle large search loads, but they need extra copies of the data and extra care to keep everything in sync, safe and up to date. With TIN, developers can do product search, filtering and ranking inside normal database queries. 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. Search results depend on small details in how words are split up and matched. A test can pass on a simple stand-in and still fail on the real system. Because Lead uses the same SQL and features, teams can test database changes and search queries on every update. 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 simpler daily work. One query language, one copy of data for basic tests, and fewer differences between laptop and production. If the extension holds up under heavy use 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.
