- Is spine/postgres-search-bundle compatible with Laravel?
- Not directly. It is a Symfony2 bundle built around Doctrine 2, so it ships no Laravel service provider, config file, or facade, and its Symfony-style service wiring will not load in a standard Laravel application. Only a Laravel app that already runs Doctrine ORM through a bridge could realistically attempt integration, and even then it needs a fork and a compatibility spike. For Eloquent applications, treat it as a reference implementation rather than a dependency.
- How do I install spine/postgres-search-bundle?
- It is installed with Composer as spine/postgres-search-bundle and then registered in a Symfony AppKernel, not in Laravel's providers array. Because the last release was in September 2016, expect Composer constraint conflicts with modern Symfony, Doctrine, and PHP versions. Any install should be fork-based with pinned versions and integration tests. Installing it directly into a new Laravel project is not recommended.
- Can I use this bundle with Laravel Eloquent?
- No. The bundle is tied to Doctrine 2 entities, metadata, and event listeners, and Eloquent models have no equivalent mapping layer for it. You would end up writing your own tsvector handling anyway. The practical path is to copy the SQL patterns such as generated tsvector columns, GIN indexes, tsquery normalization, and ts_rank into Laravel migrations and a small search service.
- Which Laravel and PHP versions does spine/postgres-search-bundle support?
- None officially. It predates modern Laravel entirely, having last been released in 2016 against Symfony 2 and Doctrine 2 constraints, which implies PHP 5-era runtimes. Running it on PHP 8.x with a current Laravel release will almost certainly fail on removed APIs and Composer constraints. Assume nothing works on your stack without a fork and a short compatibility spike.
- What PostgreSQL features does this bundle use for full-text search?
- It is built around native PostgreSQL full-text search: tsvector columns, tsquery matching with the @@ operator, GIN or GiST indexes, and ranking through ts_rank plus ts_headline for snippets. Trigger-based maintenance of the stored tsvector is a typical part of that pattern. These are exactly the primitives you can reproduce directly in Laravel without the bundle.
- How do I implement PostgreSQL full-text search in Laravel without this package?
- Add a tsvector column in a migration, either generated or trigger-maintained, and index it with GIN. Query it with whereRaw using to_tsquery or plainto_tsquery, and order results by ts_rank, optionally adding ts_headline for highlighted snippets. Wrap the query logic in a dedicated search repository or service so you can later swap to Meilisearch or OpenSearch. Stemming, stop words, and language behavior come from the PostgreSQL text search configuration you select.
- Is spine/postgres-search-bundle safe to use in production?
- Risk is high. The package has zero stars, zero dependents, no release since September 2016, and no community support or release cadence, so you should assume no upstream fixes. If you adopt it, budget for owning a fork with explicit version pins, documentation, and integration tests. Reusing only its PostgreSQL patterns carries far lower operational risk.
- How do I add a tsvector column and GIN index in a Laravel migration?
- Use DB::statement inside the migration to add the tsvector column, then create the index with CREATE INDEX ... USING GIN (search_vector). If the column is generated, PostgreSQL maintains it automatically; otherwise add a trigger to refresh it on insert and update. Run EXPLAIN ANALYZE on representative data to confirm the planner actually uses the index.
- How should I test PostgreSQL full-text search in a Laravel application?
- Test against a real PostgreSQL instance rather than SQLite, because tsvector, tsquery, and GIN behavior cannot be simulated. Cover ranking order, pagination, highlighting output, multi-word and phrase queries, and a case proving stale vectors are refreshed after updates. Also assert that the query plan uses the index at realistic data volumes so silent full scans are caught early.
- What are the alternatives to spine/postgres-search-bundle for Laravel search?
- For native search, write your own PostgreSQL FTS migrations and query builder calls, optionally using small community helpers for tsvector columns. For managed relevance, use Laravel Scout with Meilisearch, Typesense, or Algolia, or OpenSearch and Elasticsearch at larger scale. Native Postgres FTS is usually the right choice when data volume is moderate and you want to avoid operating an extra service.