Weave Code
Postgres Search Bundle Laravel Package
shopsys/postgres-search-bundle
Shopsys Postgres Search Bundle brings native full-text search to Shopsys projects using PostgreSQL, letting you index and query products quickly without running a separate search engine.
Tools to use full-text search PostgreSQL in Doctrine.
Frequently asked questions about Postgres Search Bundle
- What is shopsys/postgres-search-bundle?
- It is a Symfony bundle that exposes PostgreSQL native full-text search for Shopsys applications. It maintains searchable vectors, builds tsquery queries, and ranks results with ts_rank_cd so product and content search can run directly against PostgreSQL. The package is essentially Symfony wiring around a small SQL and query-building layer, and it is a fork of intaro/postgres-search-bundle tagged 0.1 for easier version management.
- Does shopsys/postgres-search-bundle work with Laravel?
- No. It is a Symfony bundle built from a DI extension, console commands, Doctrine event subscribers and entity mapping, so none of that wiring boots in a Laravel application. Laravel teams can reuse the underlying PostgreSQL full-text search technique, but they should not expect the package to install and behave as a Laravel search driver.
- How do I install shopsys/postgres-search-bundle?
- Install it with Composer using composer require shopsys/postgres-search-bundle, then register the bundle in a Symfony or Shopsys kernel and configure the entities you want indexed. The package assumes a Shopsys or Symfony application with Doctrine DBAL and a PostgreSQL database. There is no Laravel service provider or package auto-discovery, so installation outside Symfony is not supported.
- Do I need Elasticsearch, Algolia or Meilisearch to use it?
- No external search service is required. The bundle indexes content into PostgreSQL columns and answers queries with native full-text search operators and GIN indexes, so you avoid running and syncing a separate search engine. For catalogs in roughly the 10,000 to 10,000,000 row range this can be a defensible cost-avoidance choice when relevance requirements are modest.
- Which PHP, Symfony, Doctrine and PostgreSQL versions are supported?
- The package targets the Symfony and Shopsys stack and depends on Doctrine DBAL plus PostgreSQL full-text search features. The published metadata does not document a broad compatibility matrix, and the fork carries only a synthetic 0.1 tag, so inspect composer.json and test against your actual PHP, Symfony, DBAL and PostgreSQL versions. Do not assume Laravel version support, because none is declared.
- How does indexing and relevance ranking work?
- It maintains a search vector built with to_tsvector, matches queries built with to_tsquery or websearch_to_tsquery, and orders results by ts_rank_cd relevance. A GIN index on the vector column keeps matching fast, and a maintained search_vector column keeps queries simple. Synchronization is listener-based, which is the weakest part of the design because bulk writes, upserts and raw SQL bypass entity events.
- Is it production ready and actively maintained?
- Adoption evidence is very thin: zero stars, zero dependents, no visible CI, no release history beyond a synthetic 0.1 tag, and a fork-of-a-fork lineage. That does not mean the SQL approach is bad, but it does mean the package should be treated as an internal convenience rather than a supported community dependency. Check which upstream commit 0.1 pins to and whether Shopsys intends to track upstream before committing.
- How do I keep PostgreSQL search vectors fresh on bulk writes?
- Listener-based synchronization is not enough for bulk inserts, queue workers, upserts or raw statements, because those paths typically bypass model and entity events. Use database triggers or generated columns, or rebuild vectors in the same transaction as the write, and include a golden query set in your test suite so relevance regressions are caught. The package itself does not guarantee freshness for every write path.
- What are the alternatives for full-text search in Laravel?
- You can implement PostgreSQL full-text search directly with Laravel's query builder using a search_vector column, a GIN index and ts_rank_cd ordering, which is the same technique without the Symfony layer. Laravel Scout with Meilisearch, Algolia or Elasticsearch remains the better fit when you need typo tolerance, faceting, synonyms or very large catalogs. PostgreSQL pg_trgm is a lighter option for fuzzy matching, while TNTSearch suits small local datasets.
- Can I reuse the search logic without installing the Symfony bundle?
- Yes, and for a Laravel stack that is the recommended path. The reusable core is small: a maintained search vector column, a GIN index, tsquery construction and ts_rank_cd ordering, wrapped behind a framework-neutral search service interface. You own the migration and the freshness strategy, which is usually preferable to depending on a package whose Symfony wiring you cannot boot.
Weaver
How can I help you explore Laravel packages today?