Product Decisions This Supports
- Build vs. buy for graph data access. This package is a candidate "buy" (adopt the MIT-licensed library) for teams adding Neo4j to a PHP codebase. The decision it informs is whether a thin, protocol-level Bolt client is enough, or whether you need a higher-level OGM/client with active maintenance. Given 11 stars, zero dependents, and a final release in September 2020, the honest conclusion leans toward build/vendor or choose a maintained alternative — but the package is still useful as a reference implementation and a low-cost way to validate graph use cases.
- Roadmap: graph feature feasibility. It enables a timeboxed spike to answer "can we support recommendations, fraud rings, or permission graphs in our existing PHP stack without a service rewrite?" — a cheap experiment before committing roadmap capacity.
- Architecture: Bolt vs. HTTP for Neo4j. It supports the trade-off between Neo4j's HTTP API (simpler, more tooling, higher per-query overhead) and the binary Bolt protocol (lower latency, real sessions/transactions, tighter protocol coupling). PMs can use this to frame a performance-vs-maintenance decision rather than letting it default to whichever engineer is loudest.
- Use-case prioritization. Graph-backed features — entity resolution, social/referral graphs, knowledge graphs, access-control traversal, supply-chain lineage — can be scoped against a concrete driver choice and its maturity level.
- Dependency and vendor-risk policy. A package with no releases in ~5 years and no downstream dependents is a useful test case for your open-source intake criteria (maintenance, CVE response, protocol version support).
- Total cost of ownership conversations. Adopting this means budgeting internal ownership: forking, patching, and tracking Neo4j Bolt protocol versions. That's a real line item that should appear in the business case, not be discovered later.
When to Consider This Package
Consider it when:
- You have an existing PHP application and want to test or prototype Neo4j connectivity with minimal abstraction, and you're comfortable reading and modifying driver code.
- You're targeting older Neo4j versions (roughly 3.x–4.x era) where the Bolt protocol versions this library implements are still in use. Verify compatibility explicitly against your Neo4j server version before committing.
- The workload is internal, low-criticality, or a proof of concept — an analytics script, a migration tool, a one-off graph load — where a stale dependency won't page anyone at 3 a.m.
- You want a forkable base: small codebase, MIT license, permissive terms. If your team plans to own the driver anyway, starting from a compact Bolt implementation can be cheaper than adopting a heavier client you'd also have to learn.
- You need a protocol-level reference to understand Bolt framing while evaluating other clients.
Look elsewhere when:
- You're starting a new production integration. Prefer a maintained client (for example
laudis/neo4j-php-client, or the official Neo4j HTTP API) or a service in a language with first-class Neo4j support.
- You need Neo4j 5.x / current Bolt protocol versions, modern authentication, routing, or clustering behavior. Protocol drift is the single biggest risk here, and there's no release cadence to close the gap.
- You require security patching, SLAs, or a support path. No releases since 2020 and zero downstream dependents means essentially no community validation.
- Your team can't absorb ownership of a fork. Adopting an unmaintained driver without a named owner is how small technical debt becomes an outage.
- A higher-level abstraction (repositories, OGM, query builders) is what your feature teams actually need; this is a low-level transport.
How to Pitch It (Stakeholders)
For executives: This is a small, MIT-licensed PHP library that lets our existing PHP systems talk to Neo4j, a graph database, using its native binary protocol. It's a cheap way to test whether graph-powered features — recommendations, fraud detection, permission modeling — are worth funding in our current stack, without standing up new services. The caveat is maturity: it has a small community, no releases since 2020, and no downstream dependents, so it is not a foundation we should put on a critical path. Recommendation: fund a short, timeboxed evaluation using it as a spike, and treat any production adoption as "adopt with an internal owner" or "buy a maintained alternative," not as a free dependency. The real decision this informs is whether graph capability earns roadmap space at all — and we can answer that for a few engineering weeks rather than a quarter.
For engineering: It's a thin Bolt protocol client in PHP, MIT-licensed, small enough to audit and fork. It gets you binary protocol access — real sessions and transactions — that the HTTP API doesn't give you cleanly. The trade-offs are explicit: no release since September 2020, so Bolt protocol version coverage likely stops before Neo4j 5.x, and there's no maintainer bandwidth to lean on. Plan for a compatibility spike against our target Neo4j version first, name an internal owner before any non-prototype use, and keep the driver behind our own interface so swapping to a maintained client later is a contained change rather than a rewrite.