Mongodb Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on plumbing. This bundle replaces hand-rolled MongoDB bootstrap code: connection config, DI service registration, multi-connection management, and a Symfony profiler panel. Building and maintaining that in-house is roughly 2–5 engineering days up front plus recurring cost every time the official mongo-php-library ships a major version. Buying it (MIT, zero procurement friction) is the cheaper path unless you have unusual connection topology.
• Whether to go polyglot-persistence. Adopting this is the lowest-commitment way to say "yes" to MongoDB for a bounded context — catalogs, CMS content with variable schemas, audit/activity logs, telemetry, session stores — while the relational core stays on Doctrine. It does not force a migration decision; it makes one possible per feature.
• Abstraction strategy (the important one). Application code talks to MongoDB\Database / MongoDB\Collection from the official driver, not to a bundle-specific API. That means the bundle is swappable: if it's abandoned, you delete the config and wire the client manually. Choosing this over an ODM (or over a proprietary wrapper) deliberately keeps exit cost near zero — a roadmap-level de-risking decision, not just a technical one.
• Platform upgrade sequencing. 2.0 pins you to Symfony ≥ 5.4 and adds Symfony 8.0 support. That's the release that lets a MongoDB-backed feature survive the next framework LTS hop without a forced re-evaluation — and it converts "when do we drop this dependency?" into "when do we upgrade it?", which is the healthier roadmap question. The corollary: if a team is still on Symfony < 5.4, this package is now an upgrade blocker rather than neutral plumbing, so sequence it alongside the framework upgrade, not after.
• Feature sequencing. Because it's config-driven and supports multiple named connections, you can ship a read-only MongoDB-backed feature now, add a second connection for a multi-tenant or write-heavy workload later, without re-architecting.
• Team throughput. Profiler integration and standardized config cut debugging and onboarding time for anyone touching document storage; it also keeps engineers on the official driver's documented API rather than a bespoke one.

When to Consider This Package

Adopt when:

• You're on Symfony (this is a Symfony bundle — for Laravel, the equivalent decision is mongodb/laravel-mongodb, and this package is the wrong tool).
• You're on Symfony 5.4 or newer (including 8.0, as of 2.0.0) and your stack can absorb a major-version constraint bump.
• You want the official driver's API with framework-native DI/config, not document mapping.
• You need multiple connections, environment-specific config, or dev-time profiling of Mongo calls.
• Your CI and dev environments can run MongoDB server 5.0+ — 2.0 dropped CI coverage below that, so an older self-managed Mongo means you're testing on an unsupported combination.
• You're comfortable with the official library's semantics and don't need an ODM's identity map, Unit of Work, or lazy loading.
• You accept a small-community dependency as a contained, reversible bet.

Look elsewhere when:

• You need rich document mapping, relations, and lifecycle events → Doctrine MongoDB ODM bundle.
• You're not on Symfony, or you need one integration layer across multiple frameworks.
• You're pinned to Symfony < 5.4: 2.0 explicitly drops it, so you'd be stranded on the unsupported 1.x line and should plan the framework upgrade first.
• You require vendor-backed support, SOC2-style assurance, or a large community — single-digit-hundreds stars and no dependents is a real bus-factor signal (partly offset by active releases, including this 2.0 line that tracks the newest Symfony major).
• Your workload is fundamentally transactional/relational and Mongo is being chosen for convenience rather than fit.

How to Pitch It (Stakeholders)

Executives: This is glue, not a platform bet. It's MIT-licensed, costs nothing to adopt, and is intentionally easy to remove — all our application code uses MongoDB's official library, so abandoning the bundle is a day or two of rewiring, not a rewrite. It lets us ship flexible-schema and high-write-volume features without committing to a database migration, and it keeps us on the official driver's upgrade and security path. The 2.0 release is a good maintenance signal: it adds Symfony 8 support, so the dependency keeps pace with our framework roadmap rather than pinning us. The cost is a major-version bump that requires Symfony 5.4+ and MongoDB 5.0+ in CI — a scheduling item, not a redesign. The trade-off we're accepting is a small maintainer community; the reversible design is what makes that acceptable.

Engineering: It removes bespoke connection bootstrap, gives us DI-injected Database/Collection services, config-driven multiple connections, and a profiler panel in dev. We stay on mongodb/mongo-php-library's public API — no proprietary abstraction to escape later. In 2.0.0, Symfony 8.0 support was added and Symfony < 5.4 removed, along with CI coverage for MongoDB server < 5.0; there are no new features or deprecations beyond the constraint change. Treat it as a breaking upgrade: check our Symfony pin and our Mongo server version in CI before bumping, keep the composer constraint tight during rollout, and keep the wiring shallow so a swap stays cheap.