Full text

Appears when a type actually has a full-text index — not merely when the backend could support one, since a search box that can only ever return nothing is worse than no tab.

Ranked search runs through the provider’s own engine, with the SQL it ran available underneath:

Provider	Engine	Ranking
SQLite	FTS5	BM25
PostgreSQL	tsvector	ts_rank
SQL Server	Full-Text Search	FREETEXTTABLE rank
Oracle	Oracle Text	CONTAINS score
DuckDB	FTS extension	match_bm25

Scores are higher-is-better and provider-specific in scale, so compare within a result set rather than across backends.

No mapping needed

Searching needs no registered mapping: every provider derives the index table or column from the table and type name alone. The one exception is PostgreSQL, which needs the to_tsquery language — hence the language selector, which must match the language the index was built with or the search quietly matches nothing. Every other backend ignores it.

That same limit means the tab can tell you a type is indexed but not which fields the index covers, on the backends where the catalog does not keep the expression.

Nothing here to keep in sync

Unlike the vector sidecar, there is nothing here to keep in step. These indexes are maintained by the database itself — FTS5 triggers, generated or computed columns, an on-commit CONTEXT index — so a document edited or deleted in this tool is immediately searchable, or immediately gone. Documents written by Generate are searchable too, even though that lane maintains no other sidecar.

The exception is DuckDB, whose index is a snapshot the library rebuilds before each query rather than something the engine maintains. There the tab says plainly that writes leave it stale until your application runs a full-text query, and that this tool cannot rebuild it — doing so needs the list of indexed fields, which lives only in the MapFullTextProperty registration.