- How do I install TNTSearch in a Laravel application?
- Run composer require teamtnt/tntsearch, and for Laravel also install the official teamtnt/laravel-scout-tntsearch-driver. Publish the Scout driver config, point it at a storage path the application can write to, and run a queue worker so indexing jobs are processed. The library needs PHP 7.4 or newer plus the PDO, SQLite, and mbstring extensions, so confirm SQLite has not been stripped from hardened production images.
- Does TNTSearch work with Laravel Scout?
- Yes. The official teamtnt/laravel-scout-tntsearch-driver makes TNTSearch a drop-in Scout driver: set SCOUT_DRIVER=tntsearch and your existing Searchable trait, Model::search() calls, and scout:import command carry over unchanged. That driver swap is the lowest-friction way to add real full-text search to an existing Laravel codebase.
- What PHP and Laravel versions does TNTSearch require?
- The core library requires PHP 7.4 or higher along with PDO, SQLite, and mbstring. Laravel version support is determined by the Scout driver package rather than TNTSearch itself, so check its Composer constraints against your framework version before upgrading. SQLite is the default index backend, but a MySQL or Redis driver can be used instead if SQLite is unavailable.
- Where does TNTSearch store the index, and can I use Redis or MySQL instead of SQLite?
- By default TNTSearch writes a single index file such as articles.index into the storage folder you configure, and that directory must be writable by PHP. The index can also be stored in MySQL or Redis, with Redis support added in v4.0.0. You configure this through loadConfig alongside the connection details for the source database the indexer reads from.
- How do I keep a TNTSearch index in sync when records are created or updated?
- TNTSearch supports dynamic insert, update, and delete operations against an existing index, so content churn does not force a full reindex. With Scout, saving a model dispatches an indexing job, which is why a running queue worker is required. There is no transactional coupling between your primary database and the index, so a scheduled reconciliation job is strongly recommended to catch drift.
- Why does TNTSearch return only document IDs, and how do I load the actual models?
- The engine returns matching document IDs and relevance scores, not the documents themselves, because it only indexes the columns you gave it. You hydrate results with a WHERE id IN (...) query ordered by FIELD(id, ...) so relevance ordering survives. That is an extra round trip per search, so wrap it in a repository or use Scout's built-in hydration rather than leaving it to feature teams.
- Can TNTSearch handle multiple servers, autoscaling, or multi-tenant indexes in production?
- The index lives on local disk, with no replication, sharding, or failover, so horizontal read scaling means duplicating the index on every node and rebuilding it on each deploy. It fits monolithic or single-region Laravel apps with read-heavy traffic and roughly 10k to 1M documents. At high tenant counts, one index per tenant becomes painful, and node-level index drift stays invisible until users report missing results.
- Does TNTSearch support fuzzy search, boolean queries, BM25 ranking, and geo search?
- Yes. TNTSearch offers fuzzy search with configurable Levenshtein distance and a fuzzy_max_expansions limit, boolean query syntax, geo-search, BM25 and TF-IDF ranking, stemming for a documented set of languages, custom tokenizers, result highlighting, and text classification. Fuzzy expansion is the main tuning lever: the default of 50 expansions multiplied across terms can show up as latency spikes rather than errors on large wordlists.
- Does TNTSearch support faceted search, filtering, and aggregations?
- No. There is no faceting, no aggregation, and no filtering beyond what boolean query syntax gives you, which is the clearest feature ceiling compared with Algolia or Meilisearch. Product teams expecting refinement panels and count summaries will hit that limit quickly. If those features are on the roadmap, evaluate a dedicated search service before committing to an embedded index.
- Is TNTSearch actively maintained, and what are the alternatives?
- It is a single-maintainer project from TNT Studio funded through OpenCollective and Ko-fi, with CI badges still pointing at Travis and thin ecosystem signals, so treat it as stable and mature rather than actively evolving. The MIT license gives you a fork escape hatch, but forking means owning a search engine. Alternatives worth benchmarking are Meilisearch, Algolia, Elasticsearch, and database-native full-text options, each with its own Laravel Scout driver.