Neo4J Bundle Laravel Package

Product Decisions This Supports

• Graph-shaped features: Anything where the value is in the relationships, not the rows — recommendation/similarity engines, social/follow graphs, referral and multi-level marketing structures, fraud and abuse rings, entity resolution and master data, dependency and impact analysis, org hierarchies, permission/entitlement inheritance, asset and network topology.
• Roadmap sequencing: Whether "graph capabilities" is a real roadmap line item or a one-off experiment. This bundle is a cheap way to run a timeboxed spike before committing to a new datastore.
• Build vs buy: The bundle itself is a "buy" (adopt) decision costing roughly nothing — it is a thin Symfony integration layer over neo4j/neo4j-php-client. The expensive decision it sits on top of is adopting Neo4j as a system of record or a secondary store, and that decision is not made by this package.
• Data architecture trade-offs: Modeling relationships in Neo4j versus recursive CTEs and join tables in PostgreSQL/MySQL. The bundle lowers the cost of trying the graph path, so it makes the comparison cheaper to run rather than pre-judging it.
• Platform choice for PHP teams: If the org is on Symfony, this is the sanctioned integration path and reduces bespoke glue code. It also clarifies a gap: there is no equivalent official first-party integration for Laravel, so Laravel teams would consume the underlying client directly and own that wiring themselves.
• Operational scope: Multi-connection configuration, credentialed connections via environment variables, and container-managed client lifecycles — relevant to whether graph access is centralized or scattered across ad-hoc connection strings. As of 1.2.0, the same is true of session and transaction lifecycles: they now emit timing (Stopwatch), structured logging, and events alongside connection setup, so graph traffic is observable in the same tooling as the rest of the application rather than being a black box.
• Observability as an adoption criterion: Whether a new datastore is debuggable by the team that will inherit it. The 1.2.0 instrumentation means a spike produces timing and event data you can put in front of stakeholders to size query cost and latency, instead of relying on informal benchmarks.

When to Consider This Package

Consider it when:

• The application is Symfony (this is a Symfony bundle; it is not framework-agnostic and does not serve Laravel).
• Neo4j is already chosen or in a funded pilot — the bundle adds configuration ergonomics, service wiring, and instrumentation, not graph capability.
• You want config-driven, environment-aware connections and autowirable driver/client services instead of hand-rolled factories in each service.
• You expect more than one graph connection or environment (dev/staging/prod, or multiple databases) and want that managed centrally.
• Observability is a gating requirement: 1.2.0 extends Stopwatch timing, PSR-3 logging, and event dispatching to sessions and transactions, so slow Cypher, retry behaviour, and transaction boundaries become visible in your existing monitoring stack without custom instrumentation code — useful both for a spike (measuring before you commit) and for production operations (diagnosing after).
• You want an official-org, permissively licensed (MIT), actively maintained integration surface — the 1.2.0 observability release is a stronger upkeep signal than a maintenance-only bump, and suggests the maintainers are closing operational gaps rather than freezing the API.

Look elsewhere or proceed with eyes open when:

• The stack is not Symfony — use neo4j/neo4j-php-client directly; adding this bundle buys nothing. This applies to Laravel teams, who will not get the 1.2.0 instrumentation for free and would have to reproduce it themselves if they want equivalent visibility.
• You need an OGM / entity-mapping / schema-migration story. This is a wiring and instrumentation layer, not an ORM. Query building, Cypher authoring, and migration tooling remain your team's responsibility.
• Community depth matters to your risk model. 82 stars and 0 dependents means thin third-party usage: few Stack Overflow answers, few blog posts, no ecosystem of plugins. Weight the official backing heavily, because it is carrying most of the credibility. The instrumentation added in 1.2.0 is not a substitute for a community that has already hit the edge cases.
• You already run a custom instrumentation layer around the underlying client. 1.2.0 overlaps with what you may have built yourself; adopting the bundle now means either replacing that code or running two observability paths, so weigh the migration cost.
• The workload is transactional CRUD with shallow joins — a relational database will be cheaper to operate and hire for.
• You need a managed, fully supported vendor integration with an SLA. This is community-supported open source under MIT, not a commercial support contract; the new Stopwatch/logging/event hooks are wired into Symfony's own contracts and are only as good as your monitoring configuration.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a free, MIT-licensed, officially maintained connector that lets our Symfony application talk to a Neo4j graph database with standard configuration instead of custom plumbing. The 1.2.0 release adds timing, logging, and event instrumentation to database sessions and transactions, which means a trial run produces hard latency and cost numbers we can evaluate rather than an engineer's opinion of how it felt. It is not a platform purchase and it does not commit us to anything — it is the cheapest possible way to run a bounded proof of concept on graph-backed features like recommendations, fraud detection, or entitlement modeling. The real decision, and the real cost, is whether we adopt a graph database at all and whether the team can model and query graphs well; this package only removes the integration tax and the blind spot from that evaluation. Recommend approving a timeboxed spike, not a platform migration.

To engineering: Official Neo4j org, MIT, actively maintained — the 1.2.0 release extends the existing Stopwatch, logging, and event-bus integration from connection setup to sessions and transactions, so query timing and transaction boundaries are observable without writing our own decorators around the driver. Symfony-native configuration, autowirable services, environment-based credentials. Still a small surface area — it wires and instruments the driver; everything meaningful still happens in Cypher and the PHP client, which you can fall back to at any time without rewriting business logic. Caveats to own: minimal external adoption (low stars, no dependents), so expect to solve integration edge cases yourself; no OGM, no migrations, no query builder; the instrumentation follows Symfony contracts, so if we later move off Symfony or need equivalent visibility for a Laravel service, we rebuild it. Budget for graph data-modeling skill on the team, which is a bigger line item than the package.

Recommendation: Adopt for a scoped Symfony spike behind a single service boundary, and use the 1.2.0 instrumentation to make the spike's latency evidence part of the go/no-go decision. Do not standardize on it org-wide until the graph use case proves out and a second consumer appears.