Weave Code
Symfony Bundle Laravel Package
mongodb/symfony-bundle
Official Symfony bundle for MongoDB that integrates clients and collections with Symfony's dependency injection container, supports autowiring and multiple connections, and adds configuration, profiling, and logging hooks to reduce boilerplate when using MongoDB in Symfony applications.
(Experimental) Bundle to provide a lightweight integration of MongoDB in Symfony
Frequently asked questions about Symfony Bundle
- Can I use mongodb/symfony-bundle in a Laravel application?
- No. This package is a Symfony bundle built around Symfony's Bundle class, DI extension, and service definitions, so it provides no Laravel service provider, facade, or config-publishing workflow. In a Laravel application you should use the official mongodb/mongodb library directly, or a Laravel-specific MongoDB integration, rather than trying to shoehorn a Symfony bundle into the framework. If your estate runs both Symfony and Laravel services, it is reasonable for the Symfony side only.
- How do I install and configure mongodb/symfony-bundle?
- Install it with Composer alongside the official MongoDB PHP library, then register the bundle in config/bundles.php for the environments where you need it. Configuration lives in Symfony's config system, where you define URIs, connections, and client options for one or more clients. From there the bundle registers ready-to-use MongoDB\Client, MongoDB\Database, and MongoDB\Collection services you can inject into your own services.
- How does autowiring work for MongoDB\Client, MongoDB\Database and MongoDB\Collection?
- The bundle registers its clients in the Symfony container using the official MongoDB PHP library, so you can type-hint MongoDB\Client in a constructor and let the container resolve the named client for you. Database and collection services can be defined against a client and injected the same way, typically with named services or binding aliases per connection. With multiple connections, you should reference explicit named services or configure aliases so autowiring picks the intended client instead of a default.
- Does it support multiple MongoDB connections and named clients?
- Yes. The bundle is designed for multiple connections and named clients, each with its own URI and client options defined in configuration. That lets you separate, for example, a primary application database from an analytics or reporting cluster and inject the right client into the right service. The main caveat is naming discipline: alias or bind the clients you want autowired so a default does not silently win.
- Which Symfony and PHP versions are supported, and does it work with MongoDB driver 2.0?
- Release 0.3.1 adds support for version 2.0 of the mongodb/mongodb library, which is the current major of the official PHP driver and raises the PHP floor relative to 1.x. Because that constraint bump landed in a patch release, you should verify the exact tested intersection of ext-mongodb major, mongodb/mongodb major, PHP 8.2 to 8.4, and Symfony 6 or 7 rather than assuming the matrices compose. Check the package's composer.json constraints and CI matrix before committing, and pin versions in your lockfile.
- Is this a replacement for doctrine/mongodb-odm-bundle?
- No. This bundle wires the official MongoDB PHP library into Symfony's container, giving you clients, databases, and collections, but it deliberately does not provide an ODM with document mapping, repositories, or unit-of-work semantics. If you need managed documents and identity maps, keep doctrine/mongodb-odm-bundle. Teams that want MongoDB without Doctrine's mapping layer, and are happy to work with arrays and the driver's query API, are the intended audience.
- Is mongodb/symfony-bundle production-ready, and what is the maintenance risk?
- Treat it as a low-adoption labs project. It is published under the mongodb-labs organization, which is MongoDB's experimentation space, with no backward-compatibility promise, no formal deprecation policy, and very few stars or dependents, so you would likely be among the first production adopters. The Apache-2.0 license is clean and the fact that it tracks driver majors is a positive maintenance signal, but its continuation is not guaranteed. Plan for the possibility of vendoring or forking it if you depend on it long term.
- How should I handle upgrading to 0.3.1 with MongoDB driver 2.0?
- Upgrade deliberately rather than with a blind composer update. The 0.3.1 release changes supported major-version bounds for the underlying driver but was shipped under a patch number, so projects on a ^0.3 constraint will pick it up automatically on a routine update. Check whether the constraint accepts both 1.x and 2.x or requires 2.0 only, confirm your ext-mongodb and mongodb/mongodb versions align in local, CI, and production images, and audit your lockfile before deploying.
- Does the bundle add logging and profiling for MongoDB queries?
- Yes. The bundle adds Symfony integration hooks for profiling and logging so MongoDB activity can surface in the Symfony profiler and your logs instead of being invisible. Before enabling it in production, confirm whether the data collector redacts credentials from DSN output and exactly which commands and connection events are recorded. Profiling is a debugging aid; keep any credential-bearing configuration out of captured output.
- How do I test a Symfony application that uses this bundle?
- Boot a test kernel with the bundle registered and point the configured URI at a disposable test database, usually through an environment variable referenced in your test configuration. Because clients are container services, you can also swap in a stub or mock MongoDB\Client for unit tests of services that consume it. Keep a separate database or collection namespace per test run to avoid cross-test contamination, and assert against real driver behavior in at least a few integration tests.
Weaver
How can I help you explore Laravel packages today?