Ai Typesense Store Laravel Package

Product Decisions This Supports

• Search-infrastructure reuse (the strongest case). If Typesense is already in the stack — e.g. a Laravel Scout typesense driver powering keyword search — this bridge lets the same cluster serve vector retrieval too. That turns a "do we buy a second vector database?" question into "do we add a collection to the search cluster we already run, monitor, and pay for?" For most teams that is the single biggest cost and operational argument in this package's favour.
• Semantic search / RAG MVP scoping. It supplies the persistence-and-retrieval half of a RAG or "similar items" feature behind Symfony AI's StoreInterface, so the estimate becomes "wire up a store, generate embeddings, render results" rather than "build a vector layer." Realistic saving is weeks of integration work on the store layer, not months of the whole feature — the embedding pipeline, chunking, evaluation, and UX are still yours.
• Build vs. buy for the vector abstraction. Building a thin Typesense vector client yourself is genuinely a few days of work; this package's value is not raw capability, it's that it conforms to a shared interface (StoreInterface, plus VectorDocumentInterface as of v0.14) with sibling bridges (Postgres/pgvector, Milvus, SurrealDB, etc. in the same Symfony AI repo). That's a portability option you can't easily retrofit onto hand-rolled code.
• Metering and plan limits. The count capability (v0.14) makes "documents indexed" a first-class read, which supports per-tenant quotas, plan-tier enforcement, and "N results available" UI without a parallel bookkeeping table you have to keep in sync. Treat it as a control-plane primitive — cache it; it is not an analytics or faceting engine.
• Roadmap phasing. Phase 1: one narrow semantic feature (catalog or help-centre search) on the existing Typesense cluster, measured against current keyword relevance. Phase 2: only if retrieval quality justifies it, standardise on VectorDocumentInterface so a backend swap is a config change. Phase 3: hybrid keyword+vector ranking — Typesense's own strength, and the reason to prefer it over a pure vector DB if search relevance is the product goal.
• Explicit non-decision: this is not a Laravel package. No service provider, no publishable config, no facade, no config/ai.php entry. Adopting it means pulling symfony/ai-store into a Laravel app and writing the wiring yourself. Decide that consciously; don't let it be discovered in sprint 1.

When to Consider This Package

Adopt when:

• You are already running Symfony AI (symfony/ai) and simply need the Typesense backend — this is the intended audience, and for them it's a near-trivial choice.
• Or: you're on Laravel, already operate Typesense, and are willing to accept a Symfony-shaped dependency (symfony/ai-store + this bridge) in exchange for backend portability. Budget an explicit spike to confirm the two coexist cleanly with Laravel's container and your existing laravel/ai or custom AI code.
• Your retrieval needs fit Typesense's envelope: embeddings in the hundreds-to-low-thousands of dimensions, corpora in the low millions of documents, sub-100ms latency targets, and metadata filtering alongside vector similarity.
• You want typo tolerance and hybrid keyword+vector ranking in the same engine — the differentiator versus pgvector or a pure vector store.
• You need quota/corpus-size visibility as a product feature, not just an internal metric.

Look elsewhere if:

• You have no Typesense cluster and no other reason to run one. Standing up new search infrastructure to use a bridge package is the tail wagging the dog; pgvector on Postgres you already operate is the cheaper default.
• You need third-party validation before committing. This has 0 stars, 0 dependents, and is pre-1.0. Its credibility comes from being a component of the Symfony AI monorepo (issues and PRs live upstream in symfony/ai), not from independent adoption. There is no external production track record to point at.
• You need API stability. Ten minor releases, several with "no significant changes," a breaking-adjacent injection-hardening fix in v0.10 (remove() query-injection hardening across bridges — a reminder that these adapters are young), and interface churn as recently as v0.14. Pin the version; assume you'll do upgrade work.
• You need managed SLAs, enterprise support, or a compliance story — Typesense Cloud or a vendor-backed alternative is the answer, not an MIT bridge.
• You need real analytics. count is a collection-size primitive. Faceting, aggregation, cohort analysis, and dashboards are not in scope; pair Typesense with your warehouse.
• Your scale exceeds Typesense's comfort zone (very large corpora, or dimensions/recall requirements pushing toward HNSW-tuned dedicated engines like Qdrant or Milvus).
• You're not on PHP/Symfony at all, or your team would rather own ~200 lines of Typesense client than inherit an abstraction layer. That is a legitimate call at this maturity level.

How to Pitch It (Stakeholders)

To executives — frame it as infrastructure leverage, not a new platform:

"We already run Typesense for search. This lets that same cluster also power AI-driven retrieval, so we can ship semantic search and RAG features without buying or operating a second vector database. Concretely: no new vendor contract, no new on-call surface, no per-query vector-DB pricing — and a shared interface means we can move to pgvector or another backend later without rewriting the feature.

Two honest caveats. First, this is an early, pre-1.0 component of the Symfony AI project with no independent adoption yet — it's credible because Symfony maintains it, not because others are running it. We should treat it as a dependency we own, pin the version, and budget upgrade time. Second, it's a Symfony package, so there's integration work to do in our Laravel app; that's a sprint-one line item I want visible, not a surprise.

I'd like to approve a timeboxed spike: one narrow feature — catalog search or help-centre retrieval — measured against our current keyword results. If relevance doesn't beat what we have, we stop and we've spent a few weeks, not a quarter. If it does, we've added an AI capability at the marginal cost of some embeddings and a collection."

To engineering — be precise about what it does and doesn't buy:

"It's a store adapter: insert, query with metadata filters, remove, and (v0.14) count, all behind Symfony AI's StoreInterface, with VectorDocumentInterface letting you model records as typed objects instead of arrays. That last one is the real win — static analysis and a clean seam for swapping backends.

What it doesn't do: chunking, embedding generation, retrieval evaluation, reranking, or prompt assembly. Those are ours. And it isn't Laravel-native — expect to register the client, construct the store, and bind it in a service provider ourselves; no config publishing.

Known rough edges: pre-1.0 with frequent minor releases; a query-injection hardening fix landed in v0.10, so audit our inputs and pin aggressively; keep count off hot paths and cache it if it's rendered per request.

Proposal: timebox a spike on our most-trafficked search surface. Success criteria are relevance metrics against the current keyword baseline and p95 latency inside SLO against our existing Typesense cluster. If it clears both, we productionise behind the store interface so a backend change later is a binding swap, not a rewrite."