Ai Neo4J Store Laravel Package

Product Decisions This Supports

• Hybrid RAG as a roadmap bet, not a default. This package remains the cheapest way to test whether "vector similarity + relationship traversal" is a real product differentiator before committing to a custom retrieval layer. If the experiment fails, we've spent a spike, not a quarter.
• Build vs. buy on the retrieval layer. The add() / remove() / similarity-search-with-filter surface is thin and well-defined — and v0.14.0 tightens it further with an explicit VectorDocumentInterface and a StoreFactory for construction. Writing and maintaining a Neo4j vector adapter ourselves is still a few weeks of engineering plus permanent ownership of index configuration, filter translation, and driver upgrades. Buying here (MIT, zero license cost for the package itself) remains the correct default for a first iteration — provided we accept the Symfony coupling below.
• New in v0.14.0 — count capabilities make retrieval meterable. We can now ask a store how much it holds without pulling records. That turns several previously-ungrounded product questions into cheap ones:
  • Cost and quota modelling — per-tenant vector counts give us a defensible basis for usage tiers, fair-use limits, or per-account billing on an AI feature.
  • Observability and index health — "is this tenant's corpus actually indexed, and is it growing?" becomes a dashboard, not a support ticket.
  • Empty-state and UX decisions — knowing a store is empty lets us gate onboarding flows and "no results yet" copy on real state rather than heuristics.
  • Spike instrumentation — we can measure the graph-backed path against the incumbent store on volume as well as latency and relevance, which strengthens the decision gate described below.
• New in v0.14.0 — StoreFactory reduces adoption friction, but only on the Symfony side. Standardised, DSN-style store construction removes hand-rolled wiring for the bridges that support it. It does not remove the need for a Laravel binding; it just means our binding can be thinner. Net: a small, real reduction in the integration cost we priced in earlier.
• Interface churn at 0.x is now demonstrated, not hypothetical. VectorDocumentInterface landed as a feature in a minor release. That is exactly the kind of change that reshapes the type we'd bind against, and it validates the "wrap it behind our own contract on day one" recommendation rather than weakening it.
• Feature-level use cases worth scoping against (unchanged):
  • Relationship-constrained semantic search — "find similar documents, but only those linked to this account/entity" — where a plain vector store would force us to over-fetch and post-filter in application code.
  • Knowledge-graph-backed support or research assistants, where answers must be grounded in curated, internally-linked content rather than loose document chunks.
  • Recommendation/"more like this, and connected to this" surfaces where the graph already exists or is cheap to model.
• A forcing function on data modelling. Adopting it makes graph schema (node labels, properties, embedding dimensions, index definitions) an explicit product artifact rather than an emergent one. That's a governance win, but it must be resourced — it is not free.
• Portfolio triage — one signal moved, the decision did not. Prior assessments noted a run of releases with "no significant changes"; v0.14.0 breaks that pattern with three features, at least one of which (count, #1755) arrived from an outside contributor. That is the first evidence of a contributor base beyond the core team, and it is a mild positive for the package's durability. It does not change the recommendation: with negligible dependents and no production references, the honest decision remains "evaluate, don't standardize." Re-verify the star/dependent counts before any roadmap write-up — they are the weakest-sampled input in this assessment.

When to Consider This Package

Criteria for adoption

• The graph relationship is a hard requirement, not a nice-to-have. If a WHERE clause on columns in Postgres would solve it, this is the wrong tool.
• We already run Neo4j, or have an approved decision to adopt it. Standing up Neo4j solely to host embeddings is a large operational bill for a retrieval feature.
• Our retrieval needs filtering and similarity in one query, at a scale where post-filtering in PHP would be unacceptably slow or expensive.
• We need usage metering or index-health visibility as a first-class product capability — the new count support makes this a genuine differentiator versus thin stores that force full scans to answer "how many?"
• The team is comfortable with Cypher and with Symfony-ecosystem interfaces appearing inside a Laravel codebase (or willing to wrap them behind a Laravel contract on day one — now effectively mandatory, see below).
• The use case is exploratory or internal-facing — a place where the package's pre-1.0 status and near-zero community surface area cannot damage customer-facing SLAs.
• We accept the version pinning discipline required. This is now a firmer requirement than when this assessment was first written: Symfony AI packages ship in lockstep minor releases, and v0.14.0 added a public interface in a minor. Our composer.json will need attention on every bump, and our adapter — not our application code — must absorb interface changes.

Look elsewhere if

• You need plain semantic search. A vector column in Postgres, or an in-memory/SQLite store for prototypes, is simpler, cheaper, and has a far larger support base. Reaching for Neo4j here adds a database, a driver, and a schema for no product gain.
• You need scale confidence. Neo4j's vector index is younger and less benchmarked than dedicated vector databases. If retrieval latency is on the critical path for a high-QPS product, we'd be betting on unproven performance.
• You need ecosystem assurance. Even with an outside contribution and a more substantial release, the support surface is thin: no third-party write-ups, no Stack Overflow corpus, no hiring pool, and no signal that other teams have survived the upgrade path. Every problem is still a first-principles problem.
• The package's integration surface is assumed, not documented. The README remains a stub linking to Neo4j's Cypher manual and the Symfony monorepo — no usage example, no configuration reference, no supported-version matrix, and the changelog is a link list, not migration guidance. v0.14.0's interface addition is precisely the kind of change where release notes tell you that it happened but not what it means for you. Budget for reading source.
• Laravel-native ergonomics matter. This is a Symfony bridge, not a Laravel package. There is no service provider, no config file, no facade. StoreFactory helps with construction, but you will still hand-write container bindings and a small adapter, and absorb mismatches between Symfony's conventions and Laravel's (HTTP client, config, DI scoping). For a team without Symfony familiarity, that friction is recurring, not one-time.
• Total cost of ownership is a concern. The package is MIT, but Neo4j itself is not free at scale — licensing, managed-instance fees, backup/restore, monitoring, and Cypher-competent on-call all land on us. Price the database, not the bridge.
• It's needed in production within weeks. One feature-rich minor with an interface change is still not battle-testing. First adoption remains a discovery project.

How to Pitch It (Stakeholders)

To executives — one paragraph: "We have a candidate for testing whether our AI features get meaningfully better when search understands relationships, not just similarity — 'find me documents like this one, but only inside this customer's world.' This package is a small, MIT-licensed connector that lets us try that without building a retrieval layer from scratch, and its latest release added two things that matter to the business case: the ability to count what's stored, which is how we'd meter usage and price the feature, and a standard construction path that trims our integration work. I'm recommending a time-boxed spike, not a platform commitment: the package is still early — pre-1.0, negligible adoption, minimal documentation, and it changed a core interface in its most recent release — and the real cost is standing up and operating Neo4j. The decision I need is approval for a short evaluation with a defined kill criterion: if graph-aware retrieval doesn't measurably beat what we have, we stop and keep the current store."

To engineering — the ask: "Treat this as a thin adapter, not an architecture — and v0.14.0 is the proof. VectorDocumentInterface landed as a feature in a minor, so the types we'd bind to are still moving. Wrap it in a Laravel-side contract (VectorStore interface of our own) so the Symfony types never leak past one binding in a service provider, and so swapping to pgvector or a dedicated vector DB is a one-class change. Use the new StoreFactory to reduce construction boilerplate rather than hand-rolling it, and wire the new count() into our spike instrumentation — we want volume alongside latency and relevance in the comparison. Validate four things: (1) the actual interfaces the sibling store package exposes today, since the README still doesn't say and the changelog is a link list; (2) whether filter-plus-similarity in a single Cypher query measurably beats fetching-then-filtering in PHP at our realistic dataset size; (3) the upgrade story, given lockstep minors and an interface that just changed; (4) whether count() is cheap enough to call on a request path or only in background jobs — don't assume. Pin versions, containerize Neo4j for local dev, and write the schema (labels, properties, embedding dimensions, index DDL) down as a migration artifact — not tribal knowledge."

Framing to hold everyone to: this is a spike with a decision gate, evaluated against our existing store on latency, relevance quality, and operational cost. One more substantial release improves the odds the package survives; it does not by itself prove it works in production for anyone. Success means we can state, in numbers, that graph context improved retrieval enough to justify a new database in our stack. Failure means we learned that cheaply — which is also a good outcome, and the reason to run it.