Lead copies TIN's SQL contract, not its production index
Lead exists for one narrow job: let code written for PlanetScale TIN execute against PostgreSQL 17 or 18 before it reaches production. It supplies the tin access method, the ==> operator, TINQL parsing, tokenizer and index options, scoring functions, and two forms of highlighting. That makes it useful in development, CI, and staging, where a missing operator or invalid query shape should fail before deployment.
The trade is visible in every search. Lead stores no search data in its index. A scan reads the table's current block count, marks every heap page as a lossy candidate, and lets PostgreSQL recheck each visible row. This preserves query behavior and MVCC visibility without recreating TIN's production machinery. It also means table growth directly expands the work, which is why the README calls the extension deliberately non-production.
Version 1.0.3 needs an exact pgrx toolchain
The build instructions pin cargo-pgrx 0.19.1 and require initialization for PostgreSQL 17 or 18. You choose one matching feature when packaging, building, or running the extension. An interactive database still needs CREATE EXTENSION tin, but Lead does not require shared_preload_libraries or session_preload_libraries. That is a fairly clean runtime shape once the compiler and PostgreSQL toolchain exist.
The repository's CI shows what that toolchain entails. Its one workflow covers x86-64 and arm64 across both supported PostgreSQL majors, sets PGRX_HOME, installs PostgreSQL build packages, installs cargo-pgrx, downloads the chosen server, then runs build, Clippy, and local tests. Our 3-CPU Debian sandbox did not reproduce those preparation steps automatically, and the missing pgrx home stopped both checks.
What happened when we ran it
Our run at commit b656e2c installed 83 packages in 33 seconds. The build then ran for 70 seconds and exited with code 101. The final error came from pgrx-pg-config 0.19.1 and said $PGRX_HOME does not exist; the log did not identify any Rust source error in Lead itself.
Tests reached the same boundary. The command ran for 66 seconds, exited with code 101, and ended with the identical missing-home message while pgrx-pg-sys was preparing its build. Those results do not establish whether Lead's test cases pass after a correct pgrx initialization. They establish that a fresh Rust container cannot build or test this commit without the PostgreSQL-specific setup that the README and CI describe.
The checkout held 91 files, about 19,141 lines of source, and occupied 0.8 MB. We found one CI workflow, no Dockerfile, and no tests directory. The repository does contain local and PostgreSQL test commands through cargo-pgrx, plus an extra regression script reserved for developers with access to private TIN source. Public users cannot run that comparison suite from this repository alone.
Two open scoring reports can change ranked results
Open issue 14 reports that a committed text update can return the new row text with a stale relevance score on Lead 1.0.3. The reproduction keeps the query term and document length constant, yet the second score becomes zero. The report says matching and visibility remain correct, but ordering by the cached score can rank results incorrectly. That distinction matters if your test asserts only matched IDs.
Issue 15 finds another ranking boundary across two TIN-indexed columns. Reversing equivalent OR predicates changes which matching row receives a zero score, according to the supplied PostgreSQL 18.6 reproduction. The issue includes a query-level workaround that scores each field separately and adds the results, at the cost of more query work. Until those reports are resolved, test both matches and scores for your actual SQL shapes.
The stemmer gap can block a production migration in CI
Open issue 16 says a TIN 1.0.4 index using WITH (stemmer = 'en') is accepted in production but rejected by Lead 1.0.3 as an unrecognized parameter. That is exactly the sort of compatibility gap this project is meant to prevent: a valid production migration cannot pass through a Lead-backed CI database. The reporter's temporary choice was to use unstemmed indexes and prefix terms.
Lead still covers a meaningful portion of the surface, including expression and partial-index rechecks, explicit and implicit highlighting, and scoring at the same query level as the matching predicate. Its AGPL-3.0-or-later license is clear, and the last push on October 1, 2026 closed a change addressing five TIN divergences. GitHub listed 160 stars and four open issues, with no published release returned by the API.
Small CI databases are the right boundary
Lead makes sense when TIN is already a production choice and the alternative is skipping search SQL in CI. It gives PostgreSQL real operators and recheck behavior rather than a mock function that accepts anything. Keep fixtures small, pin cargo-pgrx 0.19.1, initialize the required PostgreSQL major, and write assertions for ranking as well as matching.
A team shopping for general PostgreSQL search should choose a production index instead. ParadeDB and PGroonga solve that different problem. Lead's value comes from being intentionally worse at retrieval while staying close to TIN's contract. The 70-second failed build in our sandbox is a useful warning: provision the documented pgrx environment first, then decide whether its remaining compatibility gaps cover the SQL your application actually ships.