Neo4J Ogm Bundle Laravel Package

Product Decisions This Supports

• Graph-shaped roadmap items vs. relational workarounds. This package exists to answer one question: "Do we need a graph data model, and can we ship it fast in PHP?" It supports scoping features whose value depends on traversal-heavy relationships — recommendations ("people who bought X also…"), social/affinity graphs, fraud-ring or entity-resolution detection, permission and org hierarchies, knowledge graphs, and multi-hop dependency mapping.
• Build vs. buy for the graph persistence layer. The OGM (object-graph mapper) abstraction is the "buy/borrow" option: it promises to let engineers model nodes and relationships as PHP classes with repository-style data access instead of hand-writing Cypher everywhere. That's a legitimate architecture option to weigh against (a) raw Cypher via an official driver, (b) a managed graph service, or (c) modeling in the existing relational database with recursive queries.
• Prototype vs. production investment. Because the abstraction lowers the cost of a spike, this is a tool for validating a graph use case with a time-boxed proof of concept — not for committing a roadmap to a library of this maturity.
• Platform fit gating for the whole feature. It is a Symfony bundle, not a Laravel package — there is no service provider, no Eloquent bridge, no Laravel-native configuration story. If the product runs on Laravel (as the framing implies), this package is effectively out of scope and the decision collapses to "pick a driver-level Neo4j client or a different data store." That is itself a product decision worth recording before engineering burns a sprint evaluating it.
• Risk register input. Nineteen stars and zero dependents is a strong negative signal on ecosystem viability; it feeds the "do we accept an unmaintained dependency on the critical path?" decision, which is a product-risk call, not just an engineering one.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony (or a legacy Symfony codebase you are maintaining), and the team is comfortable with bundle-based configuration.
• You are pinned to an older Neo4j generation (this OGM lineage targets the Neo4j 2.x era) and have no near-term upgrade path.
• The work is a time-boxed spike or internal tool, where speed of modeling matters more than long-term support.
• The team wants OGM-style object mapping and repository patterns rather than writing Cypher directly, and accepts the expressiveness trade-off that comes with an abstraction layer.
• You have a documented exit plan: the graph layer is isolated behind your own interfaces so it can be swapped for an official driver or managed service.

Look elsewhere when:

• You are on Laravel. Use a maintained Neo4j PHP client directly, or reconsider whether you need a graph database at all.
• You need modern Neo4j (4.x/5.x), current drivers, or transactional/Cypher feature parity. The abstraction will lag the database and become a ceiling.
• The feature is on the production critical path. Zero dependents and minimal maintainer activity mean no security patching, no community answers, and abandoned-dependency risk at the worst possible time.
• Your graph queries are complex or performance-sensitive. OGMs typically generate generic traversals; hand-tuned Cypher or native graph algorithms will outperform and be easier to reason about.
• A relational model plus recursive CTEs, a materialized adjacency table, or a managed graph service already covers the use case — cheaper operationally than adding a new database to the stack.

How to Pitch It (Stakeholders)

Executives: This is a small, low-maturity open-source library that lets PHP teams prototype graph-based features quickly. It is not a production foundation: 19 stars, no downstream dependents, and a Symfony-only footprint mean no support and real abandonment risk. Recommendation: approve a short, time-boxed spike (1–2 weeks) to prove or kill a specific graph use case, with an explicit rule that nothing ships to production on this dependency. Budget the real investment — official Neo4j drivers, or a managed graph service — only after the spike shows the feature moves a business metric.

Engineering: Treat this as scaffolding, not architecture. It is a Symfony bundle wrapping a Neo4j OGM, so it does not fit our Laravel stack without custom glue, and it targets an old Neo4j generation. If we spike, do it behind our own repository interfaces so the OGM is replaceable, keep Cypher-heavy paths out of the abstraction, and log the cost of every place the mapper can't express what we need. Default alternative for evaluation: a maintained driver-level client with explicit Cypher, which is less convenient to model but far safer to own.