DoctrineBundle: wiring Doctrine ORM and DBAL into a Symfony application
Symfony Bundle for Doctrine ORM and DBAL
At a glance
- What is it?
- DoctrineBundle is the Symfony bundle that registers Doctrine's ORM and DBAL as framework services. It is the glue layer, not the ORM itself, and the docs live on symfony.com rather than in the repository.
- Who is it for?
- Adopt DoctrineBundle if you are building a Symfony application that needs Doctrine ORM or DBAL and you want entity managers, connections and repositories managed by the container. Do not adopt it if you are not on Symfony, or if you want to configure Doctrine by hand: the bundle's whole value is the container integration you would be replacing.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What DoctrineBundle adds on top of Doctrine ORM and DBAL
Doctrine ORM and DBAL are standalone PHP libraries. DBAL is the database abstraction layer, handling connections, schema introspection and schema management. The ORM sits on top of it and maps objects to tables, with Doctrine Query Language (DQL) as an object-oriented SQL dialect inspired by Hibernate's HQL. Neither library knows anything about Symfony.
DoctrineBundle is the piece that makes them Symfony citizens. It registers entity managers, connections and repositories as container services, exposes the bundle configuration under the doctrine key, and provides the console commands a Symfony developer expects for schema and database work. If you have ever injected an EntityManagerInterface into a constructor in a Symfony project, DoctrineBundle is what put it there.
That distinction matters when you are deciding whether to adopt it. You are not choosing an ORM; you are choosing how that ORM gets wired into your framework. The repository is a bundle, and the README describes it plainly as the Doctrine DBAL and ORM Bundle for the Symfony Framework. Teams that want Doctrine outside Symfony have no use for it.
How the bundle is structured: config, src, templates, docs
The repository layout is a conventional Symfony bundle. The src/ directory holds the bundle code, config/ holds the service definitions that the bundle loads, and templates/ holds Twig templates the bundle ships. Tests live in tests/, and the documentation source sits in docs/ even though the rendered version is published on symfony.com.
Configuration flows from your application's YAML into the bundle, which then builds and registers the Doctrine services during container compilation. That is the reason the bundle's own README points at the Symfony configuration reference instead of documenting options itself: the surface area is large, and it is versioned alongside Symfony's documentation rather than in this repository.
The presence of UPGRADE-2.10.md through UPGRADE-3.2.md is worth noting. Each major and minor break gets its own file, which tells you the project treats backwards compatibility as something to document explicitly rather than bury in release notes. There is also a .symfony.bundle.yaml file, which is the metadata Symfony uses for bundle-related tooling.
One structural detail that shapes how you use the project: the default branch is 3.3.x, and the most recent releases listed are 3.3.2 and 2.19.1, both published on 2026-09-09. The 2.x line is still receiving releases alongside 3.x, so which branch applies to you depends on your Symfony version, not on which number is larger.
Getting DoctrineBundle into a Symfony application
The README does not include install instructions. It points to the rendered documentation at https://symfony.com/doc/current/reference/configuration/doctrine.html, and the package itself is published on Packagist under the name doctrine/doctrine-bundle, which is the identifier you would use with Composer. Because the repository gives no install command, there is nothing here to copy verbatim; follow the Symfony documentation page for the current procedure rather than a snippet from a blog post.
What the repository does tell you is where the moving parts live. The bundle is registered in a Symfony application's config/bundles.php, and its options are read from the doctrine key in the application configuration. The bundle's own service definitions are in config/ inside this repository, and the documentation source that produces the symfony.com page is in docs/.
Once the bundle is registered and the doctrine configuration parses, a Symfony application resolves Doctrine's connection and entity manager as container services. The README does not document a command for inspecting them, so verify through the Symfony console documentation rather than from a snippet reproduced here. If the container compiles and the services are present, the bundle loaded. If compilation fails, the configuration did not parse, and the error will name the offending key.
Where DoctrineBundle is the wrong layer to reach for
The most common mistake is treating this repository as the place to file ORM bugs or look for ORM behaviour. Query generation, DQL parsing, hydration and mapping annotations are Doctrine ORM concerns. The bundle registers services and reads configuration. If your DQL produces the wrong SQL, the fix is not in this repository, and the issue will be redirected.
The second limitation is scope. This bundle exists for Symfony. If your application is built on another framework, or on no framework at all, the container integration it provides has nothing to attach to, and you should use the ORM and DBAL directly. The bundle is not a portability layer between frameworks.
There is also a documentation gap worth naming. The README is short and defers almost everything to symfony.com. That is a reasonable choice for a project whose configuration surface is defined by the framework's reference documentation, but it means the repository alone will not tell you how to configure a second entity manager or what a given option does. Anyone evaluating the project from the repository only will come away with less than they need.
Finally, the dual release lines are a real operational consideration. With 3.3.2 and 2.19.1 both published on 2026-09-09, you need to know which line your Symfony version expects before you pin a constraint, and the UPGRADE files are the place that tells you what changed between them.
DoctrineBundle compared with StofDoctrineExtensionsBundle
StofDoctrineExtensionsBundle appears in the same searches as DoctrineBundle, and the two are often installed together, but they solve different problems. DoctrineBundle is the base integration: it registers the ORM and DBAL services in Symfony. StofDoctrineExtensionsBundle is an add-on that wires Doctrine extensions, the behavioural listeners such as timestampable or sluggable, into that already-registered setup.
The practical difference is dependency direction. StofDoctrineExtensionsBundle assumes DoctrineBundle is present and configured; it does not replace it, and it does not make sense on its own. If you are deciding what to install first, DoctrineBundle is the prerequisite and the extensions bundle is optional, added when you actually need one of the extension behaviours.
The same logic applies to DamaDoctrineTestBundle, which also shows up in related searches. It is a testing-oriented bundle that sits on top of the same Doctrine integration rather than substituting for it. In all three cases the distinction is the same: DoctrineBundle is the layer that puts Doctrine into the container, and the others are consumers of that layer.
Maintenance, licensing and the cost of upgrading across major versions
The repository is not archived, and the last push was on 2026-09-09, the same day as the 3.3.2 and 2.19.1 releases. That is a recent push, and the project ships releases on both the 3.x and 2.x lines, so there is no sign of one line being abandoned in favour of the other.
The upgrade cost is visible in the repository itself. Separate UPGRADE-2.10.md, UPGRADE-2.12.md, UPGRADE-2.13.md, UPGRADE-2.17.md, UPGRADE-2.18.md, UPGRADE-2.19.md, UPGRADE-3.0.md, UPGRADE-3.1.md and UPGRADE-3.2.md files exist at the top level. That is a lot of upgrade documentation, and it is a fair signal that moving between minor versions has historically required reading rather than just bumping a constraint. Budget for that reading when you plan a Symfony upgrade.
On licensing: the repository is MIT licensed. That is a permissive licence, and it is the same licence used across the Doctrine project. This is a description of the licence identifier in the repository, not legal advice; if your organisation has specific obligations around dependency licensing, have someone qualified review it rather than relying on a summary.
Editorial conclusion
Adopt DoctrineBundle if you are building a Symfony application that needs Doctrine ORM or DBAL and you want entity managers, connections and repositories managed by the container. Do not adopt it if you are not on Symfony, or if you want to configure Doctrine by hand: the bundle's whole value is the container integration you would be replacing. Before committing, read the UPGRADE-3.0 and UPGRADE-3.2 files and check which branch your Symfony version is expected to use.
Frequently asked questions
Is Doctrine an ORM?
Doctrine ORM is an object relational mapper for PHP that sits on top of the DBAL database abstraction layer, and its README describes DQL as an object-oriented SQL dialect inspired by Hibernate's HQL. DoctrineBundle is a separate piece: the Symfony bundle that integrates the ORM and DBAL into the framework.
What is the Symfony bundle in DoctrineBundle?
DoctrineBundle is described in its README as the Doctrine DBAL and ORM Bundle for the Symfony Framework. It registers Doctrine's entity managers, connections and repositories as container services so a Symfony application can inject them.
How do I install DoctrineBundle?
The README does not include install steps and points to the Symfony documentation instead. The package is published on Packagist as doctrine/doctrine-bundle, and the configuration reference is the symfony.com page the README links to.
Which branch of DoctrineBundle should I use?
The default branch is 3.3.x, and both 3.3.2 and 2.19.1 were released on 2026-09-09, so the 2.x line is still being published. Which line applies depends on your Symfony version, and the UPGRADE files at the repository root document what changed between versions.
Is DoctrineBundle the same as StofDoctrineExtensionsBundle?
No. DoctrineBundle is the base integration that registers Doctrine ORM and DBAL services in Symfony, while StofDoctrineExtensionsBundle wires the Doctrine behavioural extensions into that setup and assumes DoctrineBundle is already present.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/doctrine-doctrinebundle)