Neo4J Php Client Laravel Package

Product Decisions This Supports

This package is a driver decision, not a product decision — but it surfaces a few real product calls:

• Whether relationship-heavy features belong on the roadmap at all. Graph traversals (multi-hop) are the only reason to pay the cost of a second datastore. Candidate features: "people you may know"/social graph, org hierarchies and approval chains, permission/entitlement graphs (ReBAC), fraud and risk-ring detection, product recommendation and co-purchase graphs, data lineage, and knowledge-graph-backed search. If none of these are on the roadmap within two quarters, the answer is no and this evaluation is closed.
• Polyglot persistence: graph DB vs. staying relational. A concrete fork in the architecture roadmap — add Neo4j alongside MySQL/Postgres, or serve the same queries with recursive CTEs, closure tables, ltree, or Apache AGE. That comparison, not the library choice, is the decision worth executive time.
• Build vs. buy on the data-access layer. Options are: adopt a client library, hand-roll a thin Cypher-over-HTTP wrapper (~a few hundred lines), or wrap a third-party driver behind a repository interface. The archived status makes "buy and forget" untenable, which pushes toward wrap and own the seam.
• Sunset / consolidation. For teams already on Neo4j via this client, this is an input into "do we migrate the driver, migrate off Neo4j, or accept and isolate the risk" — a roadmap item with a deadline attached.
• Use cases this supports well as PM framing: internal tooling and POCs where dependency risk is contained; legacy PHP services already on Neo4j 3.x/4.x; graph-exploration features where query complexity, not throughput, is the constraint.

Signals to weigh: 284 stars is a modest community, the overall score (2.44) and opportunity score (1.35) are weak, and the repository is archived. For a PM, archived is the headline: no security patches, no PHP 8.3+ or Neo4j 5.x guarantees, no bug fixes, and a future migration your team funds.

When to Consider This Package

Consider it only when all of these hold:

• You already run Neo4j and have working code on this client; the switching cost (retest traversals, transaction semantics, auth) currently exceeds the archived-dependency risk, and the exposure is bounded (internal, non-regulated, or behind a stable interface).
• You need Bolt protocol support with sessions, transactions, and parameterized Cypher, and you don't want to implement the wire protocol yourself.
• You need a framework-agnostic PHP client — this is not a Laravel package; no service provider, config publishing, Octane-safe connection lifecycle, or testing fakes comes with it.
• The workload is short-lived: a POC, an internal admin tool, or a data-migration script with a known end date.
• You have verified in writing that the "Enterprise Support" claim still applies to an archived repository. Do not assume it; ask GraphAware for the support window, CVE policy, and Neo4j/PHP version matrix. If they won't confirm, treat it as unsupported.

Look elsewhere when any of these are true:

• Greenfield or customer-facing production. Procurement and security review will (correctly) fail an archived dependency. Use a maintained client from the same lineage (the community fork, laudis/neo4j-php-client), Neo4j's own official PHP driver if it meets your version targets, or the HTTP transactional Cypher endpoint with your HTTP client of choice.
• You need PHP 8.2+/8.3 and Neo4j 5.x. Compatibility is unverified and will never be fixed upstream.
• You expect Laravel-idiomatic ergonomics. You will own the glue: container bindings, config, health checks, retry policy, connection lifetime under Octane and long-running queue workers, and test doubles.
• A relational database can answer the queries. Recursive CTEs and closure tables handle many "graph" features at zero incremental operational cost. A second datastore buys you backup, monitoring, upgrade, and on-call burden.
• You need a vendor SLA, SBOM hygiene, or a supported dependency policy.

How to Pitch It (Stakeholders)

Executive summary. Graph capabilities could unlock a class of features relational queries handle poorly — recommendations, permission graphs, fraud rings. But the specific library in front of us is archived, has modest community traction (284 stars), and scores weakly on our evaluation (2.44 overall, 1.35 opportunity). My recommendation is not to adopt it as a new dependency. If we pursue graph features, we should either (a) evaluate the maintained successor driver during a two-to-three sprint spike, or (b) avoid a graph database entirely and prove the use case with recursive SQL first. If we already depend on it, contain it: pin the version, wrap it behind our own interface, and put a named migration ticket on the roadmap.

The ask. Approve a timeboxed spike (one engineer, 2–3 sprints) to benchmark the maintained alternative against this client on our actual queries, and a decision gate on whether Neo4j earns a place in the architecture at all. No production commitment until that gate.

For engineering. It's a framework-agnostic Bolt/HTTP client, not a Laravel integration — budget real work for DI, configuration, health checks, connection lifecycle under Octane and queue workers, and transaction/retry semantics. Because it's archived, we inherit every bug and compatibility gap; version-pin it, keep it behind a repository interface so the driver is a one-file swap, and add a dependency-review note so the risk is visible rather than discovered.

What we're buying and what it costs. Buying saves roughly the equivalent of a thin HTTP wrapper's worth of code today. The cost is deferred and asymmetric: no patches, no version guarantees, and a migration we fund later under whatever deadline the ecosystem imposes. The pitch isn't "this library is bad" — it's "the switching cost is low now and rises every quarter we wait, so decide now."