PlanetScale has introduced TIN, a full-text search extension for Postgres that promises BM25 relevance ranking without forcing teams to run a separate search cluster. The company announced the extension on X, claiming it works with complicated WHERE clauses, replication, backups, and maintains correct transaction visibility while being, in their words, “mind-blowingly fast.”
TL;DR: PlanetScale has launched TIN, a full-text search extension for Postgres that delivers BM25 ranking inside the database — no Elasticsearch sidecar required. In PlanetScale’s P99 benchmark, TIN sustained roughly 227 queries per second versus about 26 for ParadeDB and around 1 for native Postgres GIN, while preserving transaction visibility, replication, and backup correctness.
What Is TIN and Why Does It Matter for Postgres Users?
TIN is a Postgres extension that adds full-text search directly into the database engine, using the BM25 ranking algorithm — the same relevance model popularized by search engines like Lucene and Elasticsearch. Instead of syncing data to an external search service, queries run against indexes that live alongside your relational data.
The core pitch is architectural simplicity. According to PlanetScale’s announcement, TIN works with complicated WHERE clauses, meaning search can be combined with regular SQL filters in a single query. That combination is notoriously awkward when search lives in a separate system, because results from the search engine have to be joined back against Postgres data at the application layer.
Why does this matter? Because most applications that need search don’t need a distributed search cluster. They need relevant results over a few million rows, with correct answers under concurrent writes. Cover art: TIN is positioned exactly at that sweet spot. PlanetScale’s benchmark chart shows TIN fluctuating between roughly 200 and 290 queries per second over a ten-minute run — throughput that, if it holds in real workloads, would make embedded search viable for a large class of applications that currently maintain two systems.
Why Do Teams Usually Move Search Out of Postgres?
The traditional answer to “we need full-text search” has been to add a sidecar. Elasticsearch or OpenSearch gets deployed, a change-data-capture pipeline keeps it in sync, and the application queries both systems.
This pattern exists for a reason. Postgres’s built-in full-text search relies on GIN indexes, which handle relevance poorly at scale. In PlanetScale’s own P99 benchmark, native Postgres GIN sustained around 1 query per second — effectively unusable for latency-sensitive search workloads. GIN indexes are also expensive to update, so write-heavy tables with text columns can slow down noticeably.
The sidecar approach trades that problem for several new ones:
- Eventual consistency between the database and the search index
- A synchronization pipeline that can silently break or lag
- A second system to secure, monitor, upgrade, and pay for
- Two query languages and two result sets that must be merged in application code
- Correctness bugs when deletes or updates in Postgres don’t propagate to the index
TIN’s argument is that this entire stack exists mainly because Postgres lacked a fast, transactionally correct BM25 index. Remove that gap, and the sidecar disappears for many teams. That is the bet, at least — the benchmarks backing it come from PlanetScale itself, so independent validation will matter.
How Does TIN Actually Work Under the Hood?
TIN is built as a Postgres extension, which means it hooks into the database’s extension API rather than replacing the engine. It implements BM25 scoring, the standard ranking function that weighs term frequency, inverse document frequency, and document length to produce relevance-ordered results.
The interesting engineering problem is not the ranking algorithm — it’s making a search index behave like a Postgres index. According to the coverage of the launch, TIN uses an optimized MVCC approach, which is how it maintains correct transaction visibility. In practical terms: a row that has been updated or deleted in an uncommitted transaction must not appear in search results, and a row committed by another transaction must appear as soon as visibility rules allow.
That’s where most embedded search designs fall down. A naive implementation that keeps its own index files will drift from the transactional state of the table, returning deleted rows or missing new ones. TIN instead integrates with Postgres’s visibility machinery, so search results respect the same snapshot semantics as ordinary SQL queries. PlanetScale also states that TIN participates in replication and backups normally — a logical consequence of being a proper extension, but a property that search sidecars fundamentally cannot offer, since they live outside the database entirely.
How Fast Is TIN Compared to ParadeDB and Postgres GIN?
PlanetScale published benchmark results comparing TIN against two alternatives: ParadeDB, another Postgres extension offering BM25 search, and native Postgres full-text search with GIN indexes. The numbers, measured at the P99 latency percentile, are dramatic.
| Engine | P99 throughput (queries/second) |
|---|---|
| TIN | ~227 |
| ParadeDB | ~26 |
| Postgres GIN | ~1 |
That puts TIN at roughly nine times the throughput of ParadeDB and over two hundred times that of native GIN in this test. The benchmark chart tracks throughput over a ten-minute window: TIN’s series fluctuates between approximately 200 and 290 queries per second, ParadeDB hovers in the 20–30 range, and Postgres GIN stays near zero to 5 queries per second throughout the run.
Some context is essential. These are vendor benchmarks, run on PlanetScale’s own infrastructure with their own query mix and dataset. Real-world performance depends heavily on corpus size, query complexity, write load, and hardware. Still, even if production numbers land well below the chart, the gap is large enough that TIN’s approach clearly outperforms the alternatives under the tested conditions. Notably, runtimewire reports that PlanetScale also deliberately shipped a slow open-source testing extension, so developers can reproduce the benchmark comparison themselves rather than taking the marketing chart on faith.
Does TIN Handle Transactions, Replication, and Backups Correctly?
According to PlanetScale, yes — and this is the part of the announcement that matters more than the benchmark numbers. The company’s launch message emphasizes three properties: TIN works with complicated WHERE clauses, it works with replication and backups, and it maintains correct transaction visibility.
The transaction visibility claim is the deepest one. Because TIN integrates with Postgres’s MVCC model, search results reflect the database’s actual committed state. A search query and a plain SQL query executed in the same transaction see the same data. That eliminates an entire class of bugs — deleted documents resurfacing in search results, or new rows invisible to search for minutes — that plague externally synchronized search stacks.
Replication and backup correctness follow from the same design. TIN indexes are ordinary database objects, so they flow through Postgres’s standard replication mechanisms and are captured by standard backup tooling. Restore a backup, and the search index comes back with it, consistent with the restored data.
Why is this hard for sidecars? Because an external index has no notion of Postgres transactions. It receives change events asynchronously and applies them out of order, under lag, or not at all. TIN’s approach sidesteps that failure mode entirely — though, as with any new extension, production hardening at scale remains to be demonstrated by real users rather than by the vendor’s test rig.
What Is BM25 and Why Does It Matter for Search Quality?
BM25 is the ranking algorithm that made modern search engines feel smart, and TIN brings it directly into Postgres. Instead of treating every match as equal, BM25 scores documents based on term frequency, document length, and how rare a term is across the corpus. The result is relevance-ordered results rather than raw pattern matching. According to GeekNews coverage of the launch, TIN combines BM25 scoring with an optimized MVCC implementation, which is what allows the ranking to work without breaking Postgres transactional guarantees.
Why does this matter in practice? Postgres’s built-in full-text search returns matches, but it has no strong notion of relevance ranking out of the box. Users typing queries into a search box expect the most relevant document first, not results ordered by insertion date or primary key. BM25 solves this by rewarding documents where query terms appear frequently but penalizing very long documents that mention a term once in passing.
This is the same algorithm popularized by Elasticsearch and Lucene, so teams migrating away from a sidecar search service don’t lose ranking quality. Queries that felt good in Elasticsearch can feel comparable inside Postgres. For relevance-sensitive search — documentation, product catalogs, knowledge bases — BM25 is arguably the single most important feature TIN ships.
How Does TIN Compare to Running a Dedicated Search Engine?
The traditional answer to “we need search” has been to deploy Elasticsearch or OpenSearch as a separate service, sync data into it, and maintain that pipeline forever. TIN’s pitch is that this architecture is unnecessary overhead. As PlanetScale stated in its launch announcement, TIN works with complicated WHERE clauses, replication, backups, and maintains correct transaction visibility — all things a sidecar engine handles poorly or not at all.
Consider what the sidecar approach actually requires:
- A second database to provision, monitor, patch, and pay for
- A synchronization pipeline (CDC, triggers, or dual writes) that can silently drift
- Reconciliation logic for documents that failed to index
- Separate authentication and network paths to secure
- Backup and restore procedures duplicated across two systems
- Eventual consistency between the primary database and the search index
- A query layer that merges results from both systems
None of those problems exist when the index lives inside Postgres. A backup includes the search index. A replica serves search queries with the same freshness guarantees as reads. A transaction that inserts a row makes it searchable under the same isolation rules.
The trade-off is operational coupling. A heavyweight search workload now shares CPU, memory, and I/O with your transactional database, so capacity planning becomes one shared problem instead of two isolated ones. Dedicated engines also offer features — aggressive caching layers, vector search integrations, distributed sharding across clusters — that an in-Postgres extension may never match. For most application search, though, the simpler architecture wins.
Who Is TIN For — and Who Should Skip It?
TIN targets a specific and very common situation: teams running Postgres who need real search quality without standing up a second database. RuntimeWire’s analysis frames it clearly — TIN adds BM25 full-text search inside Postgres, backed by vendor benchmarks and a deliberately slow open-source testing extension for comparison. That makes it a strong candidate for SaaS applications, internal tools, documentation platforms, and e-commerce catalogs where data already lives in Postgres.
The profile of a good fit looks like this:
- Teams currently fighting with Postgres GIN and
ts_vectorfor acceptable latency - Applications where search freshness must match transactional data exactly
- Organizations consolidating infrastructure to reduce operational surface
- Products needing relevance ranking (BM25) rather than substring matching
- Workloads where the P99 numbers matter: sustained throughput, not just average speed
Who should skip it? Teams with search workloads that dwarf their transactional load — large-scale log analytics, massive document corpora measured in terabytes — may still be better served by a purpose-built, horizontally scalable engine. Teams already running Elasticsearch well, with mature sync pipelines and operational expertise, face a migration cost that needs justification.
The benchmark gap is hard to ignore, though. At the P99 percentile, PlanetScale measured roughly 227 queries per second for TIN versus about 26 qps for ParadeDB and near 1 qps for native Postgres GIN. If your current search setup sits anywhere near that GIN number, TIN deserves evaluation. In my opinion, the transactional-visibility guarantee alone justifies a proof-of-concept for any team burned by index drift.
How Can Developers Test TIN’s Claims Themselves?
Vendor benchmarks deserve skepticism, and PlanetScale seems to know this. The company released a deliberately slow open-source testing extension that developers can use to reproduce and compare search approaches under controlled conditions. Rather than asking the community to trust a marketing chart, PlanetScale shipped the tooling to generate your own.
The published benchmark gives you a baseline to test against. In PlanetScale’s 10-minute run at the P99 percentile, TIN sustained roughly 200–290 queries per second, ParadeDB hovered around 20–30 qps, and Postgres GIN stayed between 0 and 5 qps. Those are dramatic gaps — two orders of magnitude between TIN and GIN — but they reflect PlanetScale’s dataset, hardware, and query shape, not yours.
A sensible evaluation plan:
- Export a representative sample of production-shaped data, including your worst-case document sizes
- Reproduce queries your application actually issues, including complicated WHERE clauses combined with search predicates
- Measure P99 latency and sustained throughput, not averages — averages hide tail behavior
- Run each contender for at least 10 minutes to catch degradation under sustained load, as PlanetScale’s own chart does
- Verify that transaction visibility behaves correctly: insert a row in one session, confirm search behavior in another
- Test replication and backup/restore with the index in place
If TIN holds a fraction of its claimed advantage on your workload, the migration math changes quickly. If it doesn’t, you’ve spent a day instead of a quarter learning that.
What Does TIN Mean for the Future of the Postgres Ecosystem?
TIN continues a clear trend: pushing specialized workloads back into Postgres instead of around it. Vector search extensions, time-series tooling, and now BM25 full-text search all follow the same logic — the database is the platform, and the sidecar era of infrastructure is losing favor. GeekNews coverage highlighted exactly this combination: BM25, optimized MVCC, and benchmark performance well above alternatives, all inside the Postgres process.
The competitive layer matters too. ParadeDB already exists in this space, and PlanetScale benchmarked against it directly rather than only against the naive baseline. Competition between two in-Postgres search engines suggests the market believes this category is real. That pressure tends to produce rapid improvement, better pricing, and more honest benchmarking.
What should Postgres users watch for? First, whether TIN’s MVCC optimization holds up under adversarial workloads — heavy concurrent updates mixed with search traffic is where transactional indexing gets hard. Second, whether the extension appears in managed Postgres offerings beyond PlanetScale’s own platform, which would determine how portable the choice is. Third, whether independent benchmarks corroborate the vendor numbers over time.
The bigger story is architectural. Every workload that moves into Postgres removes an integration point, a failure mode, and a line item from the infrastructure bill. If TIN’s benchmarks survive independent scrutiny, “add Elasticsearch for search” may become the exception rather than the default answer.
Frequently Asked Questions
Is TIN a Postgres extension or a separate service?
TIN is a full-text search extension that runs inside Postgres itself, eliminating the need for a sidecar service like Elasticsearch. According to PlanetScale, it works with complicated WHERE clauses, replication, backups, and maintains correct transaction visibility.
How much faster is TIN than native Postgres full-text search?
In PlanetScale’s published benchmark at the P99 percentile, TIN sustained roughly 227 queries per second, while ParadeDB reached about 26 qps and Postgres GIN stayed near 1 qps over a 10-minute run. Vendor benchmarks should always be verified against your own workload.
Does TIN support BM25 ranking?
Yes. TIN brings BM25 relevance scoring to Postgres, the same ranking algorithm popularized by search engines like Elasticsearch. This makes it suitable for relevance-sensitive search rather than simple pattern matching.
Can developers verify TIN’s performance claims independently?
PlanetScale has released a deliberately slow open-source testing extension that developers can use to compare approaches. RuntimeWire notes that the headline numbers are vendor benchmarks, so testing against production-shaped data is recommended before adopting TIN.
Summary
PlanetScale’s TIN makes a strong case that Postgres can host serious search without a second database. The key points:
- TIN delivers BM25 relevance ranking inside Postgres, with optimized MVCC that preserves correct transaction visibility across replication and backups.
- PlanetScale’s P99 benchmark showed roughly 227 qps for TIN versus about 26 qps for ParadeDB and near 1 qps for Postgres GIN over a 10-minute run.
- Running search inside the database removes sync pipelines, index drift, and duplicated operational burden — at the cost of shared resource contention.
- PlanetScale ships an open-source testing extension, so teams can verify claims against production-shaped data before committing.
- The launch signals a broader trend: specialized workloads moving back into Postgres, with real competition emerging in the in-database search category.
If search pain is currently forcing you toward a sidecar engine, run the benchmark against your own data first. The numbers may surprise you — in either direction.