Doctrine Schema Laravel Package

Product Decisions This Supports

• Build vs. buy for cross-DBMS schema management. This package is the "buy" (or more accurately, "inherit") option for teams that need a database-agnostic schema definition layer. It converts a custom YAML schema into Doctrine DBAL Schema objects and back again, which means one schema artifact can target MySQL/MariaDB, PostgreSQL, and other platforms without hand-maintained per-vendor SQL. The build alternative — writing your own YAML-to-DBAL importer plus platform resolution — is roughly a one-to-two engineer-week effort plus permanent maintenance, so the calculus only favors buying if the package is already in your dependency graph.
• Multi-vendor / on-prem database support as a roadmap commitment. If the roadmap includes "supports customer's existing database" (a common enterprise/on-prem requirement), this package is the enabling primitive. It is the difference between "Postgres is on the backlog" and "Postgres ships this quarter."
• Packaging schema as a distributable artifact. Because schema lives in YAML rather than migrations or raw SQL, feature bundles can ship their own schema fragments and register them via an event subscriber. This supports a modular, plug-in product architecture — decoupling "which tables exist" from "which code version is deployed."
• Feature-flag and modular deployment decisions. The SchemaBuilder is event-driven and extensible: modules contribute schema at build time. That is a genuine architectural asset if the product strategy involves optional modules, tenant-specific extensions, or a marketplace of add-ons. If the strategy is a single monolithic deploy, this capability is unused weight.
• Schema export for auditability and tooling. The exporter supports generating YAML from a live Schema object — useful for documentation generation, drift detection between environments, and reviewing schema changes in code review rather than in opaque migrations.
• Not a decision this supports: schema migration strategy. This package builds and imports schema definitions; it does not version, apply, or roll back changes. Do not let it be pitched as replacing Doctrine Migrations.

When to Consider This Package

Consider it when:

• You are already inside the Ibexa DXP ecosystem (as a customer, partner, or downstream bundle author). Here the package is effectively free — it is already a transitive dependency, and adopting its interfaces is cheaper than fighting them.
• You must support more than one DBMS and want schema expressed once, in a reviewable text format, rather than per-vendor DDL.
• You are building a Symfony product with a modular/extension architecture where third parties or optional modules contribute tables, and you want an event-driven schema assembly point.
• You want schema definitions to live in version control and code review, with the ability to round-trip (import → Schema → export) for drift checks.
• You need the DBAL platform resolution work (see v4.6.32's DatabasePlatformResolver) that smooths over cross-version DBAL differences — non-trivial to get right yourself.

Look elsewhere when:

• You are not an Ibexa DXP subscriber. The license is dual: Ibexa Business Use License or GPL-2.0. There is no permissive path. GPL-2.0 is a copyleft license that will be unacceptable for most commercial closed-source products, and the BUL requires a paid DXP subscription. Note the repository reports NOASSERTION — legal review is mandatory, not optional, before this enters a dependency manifest.
• Ecosystem signals are near-zero. Four stars, zero dependents, and release notes that are overwhelmingly "No significant changes." This is not a community-supported library; it is an internally maintained component published for the vendor's own release train. Treat it as vendor-coupled, not as an independent open-source bet.
• You need migrations, not just schema. Pair it with Doctrine Migrations or a comparable tool; do not expect this to cover change application, rollback, or data migration.
• You are on older PHP/Symfony. v5.0 requires PHP 8.3+ and Symfony 7; v4.6 is the LTS-ish line for older stacks. Confirm your platform baseline before assuming compatibility.
• You want a mature, documented developer experience. The README covers three interfaces and one event subscriber example. There is no tutorial, no YAML format specification, no migration guide. Expect to read source to understand the schema format — budget for that in the estimate.
• You need long-term support guarantees independent of the vendor. Releases are batch-published alongside DXP versions; there is no visible independent roadmap or community governance.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, focused component from the Ibexa DXP platform that lets us define our database schema once, in a readable YAML file, and target multiple database engines from that single definition. It matters if — and only if — multi-database support or a modular, plug-in product architecture is on the roadmap. It is not a general-purpose library: it is dual-licensed under the Ibexa commercial license or GPL-2.0, which means adopting it outside an existing Ibexa subscription carries real legal cost and a copyleft obligation. The recommendation is to adopt it only if we are already Ibexa customers, or if we are prepared to accept GPL-2.0 terms; otherwise the honest comparison is one to two engineer-weeks to build an equivalent internal layer under our own license.

For engineering — the substantive case: It provides three autowired Symfony services — SchemaImporterInterface (YAML → Doctrine\DBAL\Schema), SchemaExporterInterface (Schema → YAML), and SchemaBuilderInterface (event-driven assembly of multiple schema sources). The SchemaBuilder event pattern is the interesting part: SchemaBuilderEvents::BUILD_SCHEMA lets each module or bundle contribute its own schema file at a defined priority, so schema composition scales with the module system instead of accumulating in one migration directory. It also handles DBAL platform detection across versions, which is the part that always breaks when you support more than one database.

The caveats to state plainly in the same breath: the YAML format is undocumented outside the source, the repo has four stars and zero dependents, releases are almost entirely housekeeping, and the license requires legal sign-off. This is vendor infrastructure we would be riding, not a community library we would be investing in. Frame the decision as "are we an Ibexa shop?" — if yes, this is free leverage; if no, this is a licensing and maintenance liability that a modest internal build would avoid.