- What is pmatseykanets/laravel-scout-postgres used for?
- It is a Laravel Scout engine that stores searchable model data in PostgreSQL tsvector columns and uses GIN indexes and tsquery/ts_rank for full-text search. It fits Postgres-backed Laravel apps where search is secondary, such as catalog lookup, admin filtering, or internal tools. It is not a replacement for relevance-heavy search products that need typo tolerance, synonyms, faceting, or semantic search.
- How do I install and configure this PostgreSQL Scout driver in Laravel?
- Install with composer require pmatseykanets/laravel-scout-postgres, publish the package config, and set SCOUT_DRIVER=postgres. You then add a tsvector column to the searchable table—either a generated column on PostgreSQL 12+ or a trigger-maintained column—create a GIN index, and backfill existing rows. The real setup work is schema design: choosing source text columns, concatenation and setweight A/B/C/D weighting, and the text search dictionary.
- Which Laravel, Scout, PHP, and PostgreSQL versions does it support?
- The repository's last release was January 2021, and it predates Laravel 9–11 and Scout 10 changes to the Engine contract. Compatibility across Laravel, Scout, PHP 8.1+, and PostgreSQL is not verified, so a spike is mandatory before adoption. Expect to vendor or fork the package and patch method signatures such as paginate, mapIds, and lazyMap for current Scout versions.
- Does it support typo tolerance, synonyms, or faceting?
- No. Ranking is ts_rank-based and dictionary-driven, so typo tolerance, fuzzy matching, synonyms, faceting/aggregations, and API-style highlighting are not provided out of the box. If product expectations were formed on Algolia or Meilisearch, this can feel like a relevance regression even when it is adequate for simple lookup. You can add some behavior through PostgreSQL dictionaries and custom SQL, but that becomes your product decision and maintenance burden.
- Can I still use Scout where() filters and Eloquent scopes with this driver?
- Yes. Search results are returned as Eloquent builders, so Scout where() constraints and existing model scopes still apply. That is a major simplicity win over external engines, where filterable attributes often need to be replicated into the search index. It also means authorization and tenant scoping can stay in familiar query code.
- How does ranking work and can I tune relevance?
- Relevance comes from PostgreSQL full-text search: tsvector documents, tsquery queries, and ts_rank scoring, with dictionaries controlling stemming and stopwords. You tune it through schema and migrations by choosing text sources, concatenation, weights A/B/C/D, and the installed text search dictionary. There is no managed search console for relevance tuning, so language and ranking choices live in your database migrations.
- What are the production risks of using PostgreSQL full-text search with Laravel Scout?
- The main risks are staleness and silent truncation. tsvector has a hard 1 MB limit, so oversized documents can be partially unsearchable; guardrail indexed text length. Trigger-maintained columns can drift if raw SQL or bulk loads bypass triggers, and GIN index builds on large tables should be planned concurrently and off-peak. Because the package is dormant, you also need an owner to patch Scout contract changes.
- Can I use this package with MySQL or SQLite?
- No. The driver is PostgreSQL-specific by design and relies on tsvector, tsquery, ts_rank, and GIN indexes. There is no portability story for MySQL-only or SQLite estates. For other databases you would use Scout's database engine, an external engine, or a different package.
- How should I test this driver in CI?
- Test against a real PostgreSQL instance in CI, not SQLite, because the driver depends on Postgres full-text search types and indexes. Use Laravel's RefreshDatabase or migrations to create the tsvector column and GIN index, then assert that searches return expected models and that Scout where() filters still apply. Include a test for text-length guardrails and a check that trigger-maintained columns update after writes.
- What alternatives exist and is this package still maintained?
- Alternatives include Scout's database engine for simple LIKE searches, Algolia, Meilisearch, or Typesense when relevance quality matters, and raw PostgreSQL full-text search or pg_search if you want more Postgres-native control. This package is effectively single-maintainer and dormant—last release January 2021—so treat it as a small driver you may need to fork. It can still be a good fit for a Postgres monolith if you accept ownership of the fork and keep the scope to secondary search.