Neo4J Bolt Laravel Package

Product Decisions This Supports

• Graph roadmap gate: Informs whether a graph-backed capability (recommendations, fraud/ring detection, customer 360, knowledge graphs, permissions/lineage graphs) warrants investment — and, more specifically, whether Neo4j is the right store versus relational, JSON columns, or search. The package only answers "can we reach Neo4j cheaply from PHP?"; it does not answer "should we build a graph feature?"
• Build vs. buy vs. adopt: Archived with 42 stars, zero dependents, and a low package score, any adoption converts into a de facto fork and own decision. That is directly useful evidence for standardizing on a maintained Neo4j PHP client (e.g. laudis/neo4j-php-client) or a managed graph offering with an HTTP API, rather than carrying protocol code internally.
• Dependency and platform risk policy: A concrete test case for a standing rule about unmaintained dependencies in long-lived Laravel applications — no security patches, no new PHP/Laravel support, no Bolt protocol updates, no community troubleshooting at this adoption level.
• Total-cost-of-ownership framing: Makes the hidden PM budget visible — fork maintenance, CVE response, PHP upgrade work, Neo4j compatibility testing, and on-call ownership for graph connectivity — none of which appears in a proof-of-concept estimate.
• Legacy exit planning: If it already exists in a codebase, it justifies prioritizing migration behind a repository/adapter interface so feature work is insulated from the swap.
• Due diligence hygiene: A reusable example for architecture and vendor reviews of the gap between "works in a spike" and "safe to operate." Note that any high "opportunity" signal in this dataset reflects low competition in the niche, not product viability.

When to Consider This Package

Consider it only under narrow, time-boxed conditions:

• You are maintaining a legacy system already depending on it, pinned to a PHP 5.6–7.x / Neo4j 3.x-era stack, and the goal is minimal, reversible change — not new features.
• You are running a throwaway protocol-level spike in an isolated environment to validate raw Bolt connectivity or PackStream behavior, with explicit acknowledgement that the dependency is archived.
• You need a reference implementation to understand Bolt wire behavior before adopting or building a maintained client.
• You have a named owner, a funded migration ticket, and contract tests isolating it behind an internal Neo4jClient interface before anything reaches users.

Look elsewhere when:

• You are building new production features on Laravel 10+/PHP 8.x.
• You need maintained support for modern Neo4j, transactions, routing, connection pooling, TLS/auth changes, or security patches.
• You require Composer hygiene, vendor/security review approval, or a supported dependency in composer.lock.
• You need a Laravel-native experience — service provider, config publishing, facades, testing fakes, observability. There is none; you wire it yourself.
• The path is revenue-critical or customer-facing under SLA. For simple read-only graph lookups, Neo4j's HTTP API is the lower-risk access path; the driver is not the scaling lever — Neo4j cluster design and Cypher performance are.
• Your team cannot own protocol-level code. Most product teams should not.

How to Pitch It (Stakeholders)

Executive summary: This is an archived, low-adoption PHP driver for Neo4j's Bolt binary protocol — a plumbing component, not a strategic dependency, and not a Laravel package. It should not be used for new product work. If graph capabilities are on the roadmap, the decision to fund is "supported Neo4j client or managed graph service," not "build on an unmaintained library." Treat adoption as a make-or-buy decision in disguise: you would be buying the maintenance obligation.

Engineering summary: Treat it as a reference implementation, not a foundation. It offers raw Bolt access, PackStream serialization, session/query execution, and streamed results — enough for a spike, with no pooling, retries, observability, or Laravel ergonomics. If it exists in a legacy codebase, isolate it behind an adapter/repository contract, hydrate results into DTOs so Bolt types never leak into controllers or domain code, keep all Cypher in repositories, use {name} placeholders (never string interpolation), run blocking calls off the request path, and add contract tests against the exact Neo4j/Bolt version you ship. Open a migration ticket on day one; --ignore-platform-reqs is a red flag, not a fix.

Recommended position: Do not adopt for new work. Allow only for legacy containment or a short-lived, explicitly non-production spike, with a named internal owner, a documented exit criterion, and a funded migration path to a maintained driver or HTTP API.