Ai Postgres Store Laravel Package

Product Decisions This Supports

• Feature roadmap: semantic and hybrid search without a new vendor. The package is a PostgreSQL/pgvector bridge for Symfony AI's Store interface — meaning our existing managed Postgres can back embedding persistence and similarity search. It supports vector and halfvec types, pgvector distance operators (<->, <#>, <=>), ANN indexing (HNSW/IVFFlat via pgvector), and native PostgreSQL full-text search. That last point is the strategic one: hybrid retrieval (vector + keyword) in a single database is a differentiated capability we can ship as an incremental feature rather than a new platform bet.

• Build vs. buy: buy the adapter, not the database. We do not build vector storage ourselves, and we do not take on a second datastore (Pinecone/Weaviate) unless scale forces it. Adopting this bridge means our vector layer is a thin, replaceable abstraction over infrastructure we already operate. The reverse — bespoke SQL for embeddings, distance functions, and index tuning — is a multi-week build with ongoing DBA overhead and no product-visible upside.

• Concrete use cases worth writing tickets for:

  • Semantic product/content discovery — "more like this," fuzzy intent matching, cross-lingual retrieval where keyword search fails.
  • Recommendations — nearest-neighbor over user/item embeddings using Postgres we already back up and monitor.
  • Retrieval for RAG / internal assistants — chunked docs stored alongside their metadata, retrieved with filters.
  • Hybrid search refinement — "similar to X, but only in category Y," expressed as vector distance plus SQL WHERE predicates. This is where most of our quick wins live, because it degrades gracefully to existing filters.
  • Admin/ops dashboards — index size, embedding coverage, "documents with no embedding yet." Cheap visibility, previously bespoke SQL.

• Pagination and result-count UX are now unblocked. Since v0.11.0 the store supports clear(); since v0.14.0 it exposes count capabilities, plus a VectorDocumentInterface that lets us map our own domain models (Product, Article) into the store instead of an opaque array. For a PM this matters twice: it makes paginated semantic results shippable (search UIs need a total), and it makes "N results found" / facet counts achievable without inventing aggregate queries.

• Cost and lock-in posture. Vector search rides on infrastructure we already pay for, with no per-vector pricing and no egress story. If we outgrow pgvector, the Store interface is the seam we swap behind — so this is a reversible architectural decision, which is the main thing a roadmap needs from it.

• A realistic adoption verdict: this is a pilot/trial-grade dependency, not a load-bearing platform choice today. Two stars, zero dependents, version 0.x, and a Symfony-first (not Laravel-first) design. Fund it as a time-boxed spike behind an adapter, with a documented exit path, rather than as a committed roadmap dependency.

When to Consider This Package

Adopt when:

• We already run PostgreSQL 13+ and can provision the pgvector extension across local, CI, staging, and production — with DBA or platform sign-off, not a surprise at deploy time.
• The requirement is genuinely vector similarity and/or hybrid retrieval, not simply "AI feature" — if keyword search suffices, this is overkill.
• Expected corpus is in pgvector's comfortable range (roughly low millions of vectors, depending on dimensions and index type). Benchmarked, not assumed.
• We need metadata filtering alongside similarity — the Postgres advantage is that filters are just SQL.
• The team accepts a Laravel-side adapter layer around Symfony AI contracts, and can pin versions.
• Roadmap has room for a time-boxed evaluation with an explicit go/no-go gate.

Look elsewhere (or defer) when:

• Laravel-native ergonomics are the priority. Eloquent has no native vector column type; migrations and casts require raw SQL or Doctrine DBAL. If that friction is unacceptable, a Laravel-first vector package is a better organizational fit — same database, less glue.
• Scale exceeds pgvector's comfort zone, or we need multi-region replication, aggressive QPS on ANN queries, or elastic scaling that a managed vector service does better.
• We don't control Postgres. Managed plans that don't permit extensions, or a platform team that won't approve schema changes, kill this quietly.
• The dependency surface is unstable in a way we can't absorb. 0.x with a Symfony-oriented API means interface churn; if we can't staff a small adapter and regular upgrade testing, defer.
• Exact, real-time counts are a hard product requirement at high traffic. Count queries over large vector tables get expensive; only proceed if approximate or cached counts are acceptable.
• No appetite for a spike. At two stars and zero dependents, adopting without a validation phase is a bet on one maintainer's roadmap.

Gate criteria for the spike: pgvector provisioned in CI; 3 real queries benchmarked for latency and recall against representative volume; count-query latency measured; adapter proven with one domain model mapped to VectorDocumentInterface; written fallback plan.

How to Pitch It (Stakeholders)

For executives — one paragraph: "We can add semantic and hybrid search to the product using the PostgreSQL database we already run, by turning on a well-established open-source extension (pgvector) and adding a thin integration layer. That means AI-grade search — 'find things like this,' retrieval for assistants, recommendations — without buying a vector database, without a new vendor contract, and without migrating our data. The integration package itself is early-stage (open source, MIT, pre-1.0, small community), so the recommendation is a short, bounded pilot — roughly two to four weeks — behind an internal abstraction that lets us swap it out if it disappoints. Total downside is bounded engineering time; total upside is a search capability we currently can't offer. Expected payoff: we avoid a third-party vector service, keep data in our own infrastructure, and get pagination and result counts as part of the same work."

For engineering — the ask:

• Bind the store via a Laravel service provider; do not leak Symfony types into controllers. One adapter, one seam.
• Use Doctrine DBAL for vector columns, migrations, and tuned count queries; Eloquent won't help here.
• Pin symfony/ai and symfony/ai-postgres-store to ^0.14; audit any custom store/document implementations against VectorDocumentInterface.
• Treat counts as a scaling risk from day one: decide exact vs. cached vs. approximate before the feature ships, and instrument count and query latency.
• Own the operational surface: pgvector provisioning checks in CI, query timeouts, index health, and a documented fallback (including managed vector services) if load degrades.

What we are explicitly not claiming: that this is production-hardened. It is a small, early package on a fast-moving 0.x interface, maintained upstream in the Symfony AI monorepo. The pitch is a cheap, reversible experiment on infrastructure we already own — not a platform commitment.