- How do I install symfony/ai-neo4j-store in a Laravel application?
- Install it with Composer using composer require symfony/ai-neo4j-store, and confirm that the required Neo4j PHP client is also installed. You then configure a Neo4j connection and create a vector index before the store is usable. There is no Laravel-specific installer or publishable config, so expect to wire the driver manually in a service provider.
- Does symfony/ai-neo4j-store work with Laravel out of the box?
- No. The package is a Symfony AI Store bridge, not a Laravel package, so it ships no service provider, config file, facade, or Artisan commands. Laravel can consume Symfony components, but you must bind the Symfony AI vector store contract yourself. Budget for a thin internal adapter layer even if the code volume is small.
- How do I create the Neo4j vector index required by Symfony AI Store?
- You create it with Cypher DDL that defines the node label, embedding property, dimension count, and similarity function. That step must run before the store can perform similarity search. Keep the Cypher in version-controlled migrations or a deployment step rather than a developer console, because it is schema ownership, not application setup.
- Which Laravel and PHP versions does symfony/ai-neo4j-store support?
- The package does not publish Laravel-specific version constraints because it is a Symfony AI component. Check its composer.json for the required PHP version, Symfony AI Store contract version, and Neo4j client dependency, then test against your target Laravel release. Because the contract belongs to Symfony AI rather than Laravel, framework upgrades and backend swaps are separate concerns.
- When should I use Neo4j vector search instead of pgvector in Laravel?
- Use it only when retrieval genuinely needs graph traversal alongside similarity search, such as finding embeddings then following relationships in the same query. If you only need nearest-neighbor search, pgvector or an in-memory store delivers the same user outcome with less operational surface. Neo4j's vector index is a graph database feature, not a purpose-built vector engine, so benchmark latency and scale before assuming parity.
- How do I bind the Symfony AI vector store interface in Laravel's container?
- Write your own service provider that constructs the Neo4j client and the Symfony AI Neo4j store adapter, then binds the vector store interface as a singleton. Register that provider in your application bootstrap and inject the interface where retrieval is needed. The package provides no Laravel provider, so this wiring is entirely your responsibility.
- Is symfony/ai-neo4j-store production ready?
- Treat it cautiously. Releases are pre-1.0, currently around v0.8.0, with very low adoption signals such as one star and zero dependents. The synchronized monorepo tags suggest shared release cadence rather than independent hardening, so interfaces can move without a major version. Pin versions, add integration tests, and have a fork, vendor, or swap plan before production use.
- How do I handle embedding dimension changes or reindexing with Neo4j?
- A dimension change is a full index rebuild, not a normal migration. If you change the embedding model, you must re-embed the corpus, recreate the vector index with the new dimension count, and repopulate it. The package provides no migration or reindex tooling, so design and own that backfill path before committing.
- Can I filter Neo4j vector search results by metadata or graph relationships?
- The bridge exposes Neo4j's vector index through the Symfony AI Store contract, and richer filtering generally depends on the Cypher and query capabilities that contract supports. The README is a stub with no worked examples for filters, remove operations, or dimension handling. Validate the exact behavior against the Symfony AI contract and cover it with your own integration tests.
- What are the alternatives to symfony/ai-neo4j-store and where do I get support?
- For Laravel teams without a graph retrieval requirement, pgvector, a dedicated vector database, or an in-memory store for small corpora are simpler choices. Support for this bridge runs through the main symfony/ai repository's issues and pull requests, not the package repository itself. If Neo4j is already a first-class system in your estate and graph-aware retrieval is concrete, the bridge can fit, but plan for upstream concentration and Neo4j operations ownership.