Ai Redis Store Laravel Package

Product Decisions This Supports

• Build vs. buy for vector storage. The package makes "use the Redis we already run" a credible answer to "which vector database do we buy?" It wraps Redis's native vector search (FT.CREATE for indexing, FT.SEARCH with KNN / DIALECT 2 for similarity) behind a store interface, so the decision shifts from a new vendor contract to enabling a Redis module and writing (or sourcing) a thin adapter.
• Feature bets it unblocks, at low incremental infrastructure cost: semantic/similar-item search, RAG retrieval over a knowledge base, recommendations, near-duplicate and anomaly detection. Each is a query against an existing embedding pipeline rather than a new platform.
• Framework strategy — the decision that matters most for a Laravel shop. This is a Symfony AI Store bridge, not a Laravel package (0 dependents, Symfony-first). Adopting it in a Laravel codebase is an adapter investment, not a composer require. The PM call is: fund a small, self-contained adapter for a Laravel Redis client (Predis/PhpRedis), or pick a Laravel-native vector path. v0.14's VectorDocumentInterface is what makes the adapter cheap and testable — it gives us one stable contract (id, vector payload, metadata) instead of mapping into undocumented Symfony internals. Code against that interface in a shared PHP library and the Redis implementation becomes swappable.
• Capacity governance as a roadmap item. v0.14's count support turns "how big is our index?" into a first-class, cheap call instead of a manual FT.INFO chore. That converts vector storage into a budgetable line item with quotas and alert thresholds — a prerequisite for putting AI features on shared Redis without surprises.
• Migration optionality (de-risking the wrong-choice scenario). The abstracted document contract and drop-in store API mean a later move to Qdrant, pgvector, or Milvus is an integration task, not an application rewrite. This lowers the cost of being wrong, which is usually the real blocker in vector-store procurement.
• Roadmap unlock: hybrid search. RedisSearch's keyword filters plus KNN vectors support filtered semantic search (tenant, category, date, permission scoping) without bolting on a separate search engine.
• Roadmap constraint to plan around. Pre-1.0 (currently v0.14, Sept 2026), no GPU acceleration, and practical index sizes around ~1M vectors per index before manual sharding. Anything on the roadmap needing >10M vectors or multi-tenant index isolation needs a different answer, decided now rather than at scale.

When to Consider This Package

Adopt if:

• Redis 7.0+ with the AI/search modules is already deployed, operated, and monitored by your team — the cheapest possible marginal cost.
• Your use case is latency-sensitive similarity search (recommendations, semantic search, dedupe) over a small-to-medium corpus (comfortably under ~1M vectors per index; up to ~10M only with deliberate sharding work).
• You are Symfony-based, or you're Laravel-based and willing to fund a bounded adapter against VectorDocumentInterface — a few days of work, unit-testable, and reusable across projects.
• You want MIT-licensed components, no per-query fees, and a credible exit path to another vector store.
• You need index-size telemetry for quotas or capacity dashboards (count in v0.14 makes that a first-class call).
• You're running a time-boxed spike or prototype where proving the AI feature matters more than long-term backend commitment.

Look elsewhere if:

• You need scale beyond Redis's native limits (>10M vectors, distributed sharding, GPU-accelerated indexing) or per-tenant index isolation as a product requirement. Partitioning here is a design decision you own, not a feature.
• Your stack is Laravel-first and nobody will own the adapter. The glue is small but real, and it becomes abandoned glue the moment the owning team rotates. A Laravel-native or DB-native (pgvector) option is a lower-total-cost default in that case.
• You need managed operations, SLAs, or enterprise support — Redis is yours to tune: memory policies, index design, eviction behavior under pressure.
• You need API stability guarantees. This is 0.x; pin versions and read minor-release notes. The relevant risk is muted because it lives inside the main symfony/ai monorepo with an active release cadence (v0.4 → v0.14), so abandonment risk is low even at 1 GitHub star.
• You require ACID-consistent hybrid transactional + vector workloads, real-time schema changes, or similarity metrics beyond Redis's defaults.

How to Pitch It (Stakeholders)

For executives: "We already run Redis. This lets us use it as the vector store behind AI features — semantic search, recommendations, duplicate detection — instead of buying a managed vector database with per-query pricing. No new infrastructure, MIT-licensed, and low latency. Two things in the current release make it a manageable bet rather than a prototype: we can now read index size directly, so vector storage becomes a budget line with quotas and alerts like any other; and the document contract is abstracted from Redis, so if we later outgrow it, we swap the backend instead of rewriting the product. The honest caveats: it's pre-1.0, it's Symfony-native (our Laravel path needs a small adapter), and it realistically serves corpora in the low millions of vectors before we'd need to re-architect. I'd recommend we approve it for scoped pilots with a defined volume ceiling, not as an org-wide standard yet."

For engineering: "Drop-in vector store over Redis: FT.CREATE for indexing, FT.SEARCH with KNN/DIALECT 2 for similarity, wrapped behind a store API. It's part of the main symfony/ai repo, so it tracks that release train rather than living as a one-maintainer side project. Two seams make it usable outside Symfony: VectorDocumentInterface (implement once — id, vector, metadata — and keep our code independent of Redis's encoding) and count (cheap index-size and filtered counts; wire into health and metrics endpoints, and use it as a pre-flight guard before expensive KNN queries). Tradeoffs: pre-1.0, so pin versions; CPU-only indexing; ~1M vectors per index as the practical starting ceiling; multi-tenancy is a naming/partitioning convention we design, not something the package gives us. For Laravel: budget a contained adapter over Predis/PhpRedis and own it explicitly — treat it as internal infrastructure with a named owner, not a dependency we assume will maintain itself."