Core Persistence Laravel Package

Technical Evaluation

Assessment: this is not a Laravel package, and should not be treated as one. ibexa/core-persistence is an internal component of Ibexa DXP (formerly eZ Platform), extracted into its own repository so that the Ibexa monorepo can version its storage layer independently. The README makes the intended consumption path explicit: install Ibexa DXP, and this package arrives as a transitive dependency. There is no standalone usage documentation, no example bootstrap, and no public API surface described independently of the parent platform. Any evaluation framed as "can we drop this into a Laravel app" should begin with the assumption that the answer is no, and then test whether that assumption holds.

Architecture fit — poor for a Laravel codebase. The package implements Ibexa's persistence SPI: Doctrine DBAL-backed gateways, handlers, and mappers that operate on Ibexa value objects (Content, ContentInfo, Location, Section, URL). It presumes Ibexa's schema, its migration set, its Symfony service container wiring, and its SPI contracts as the caller-facing boundary. Laravel's persistence idiom is the opposite: Eloquent models, active-record-style repositories, and a query builder over Illuminate\Database. There is no shared abstraction to bridge them. Installing this package into a Laravel project yields classes you cannot call meaningfully, because the collaborators they depend on are defined in ibexa/core and the surrounding bundles, not here.

Integration feasibility — technically installable, practically inert in isolation. Composer will resolve it, but you inherit a dependency graph pinned to specific Doctrine DBAL and Symfony major versions, plus a schema that only Ibexa's migrations know how to create. The realistic integration is not package-level but platform-level: run Ibexa DXP as a content service and consume it from Laravel over REST or GraphQL. That is a fundamentally different decision with a fundamentally different cost profile.

Technical risk — concentrated in licensing. The package is dual-licensed: Ibexa Business Use License (requires a paid DXP subscription) or GPL-2.0 copyleft. GitHub reports NOASSERTION, which means automated scanners (Snyk, FOSSA, Black Duck) will flag it and block the build until a human clears it. GPL-2.0 imposes distribution obligations and is incompatible with Apache-2.0 and GPL-3.0 downstream; the BUL path avoids copyleft but converts an OSS dependency into a recurring commercial line item. This is a legal gate, not an engineering one, and it should be resolved before any POC code is written.

Adoption signal is effectively zero. Three stars and zero dependents confirm the package is not independently consumed — it ships inside Ibexa. The opportunity: 64.49 score should not be read as demand; it is almost certainly a function of low existing adoption (little competition for a niche) rather than unmet market need. The 2026-08-20 last-release date is also anomalous relative to the copyright range and should be verified directly on Packagist before it is used in any planning artifact — treat it as a data-quality flag, not a maturity signal.

Key questions for the review:

1. Are we solving a content-management problem, or a generic persistence problem? If the latter, this is the wrong tool entirely.
2. Are we already an Ibexa DXP customer, or willing to become one? If no, licensing alone likely ends the evaluation.
3. Will the resulting system be distributed to customers, or operated internally only? This determines whether GPL-2.0 obligations bind.
4. What is the exit cost if Ibexa is abandoned or repriced? Content stored in an Ibexa-shaped schema is not portable by default.
5. What Laravel-native alternative covers 80% of the requirement — Eloquent plus a repository layer, plain Doctrine DBAL, or a headless CMS with a documented API?

Integration Approach

Stack fit — recommend against package-level integration. Ibexa is Symfony-based; Laravel is a different framework with its own container, routing, ORM, and migration system. Two realistic patterns exist, and neither vendors core-persistence into the Laravel app:

• Headless sidecar (recommended if content management is genuinely required). Run Ibexa DXP as an independent service with its own database. Laravel consumes content via Ibexa's REST or GraphQL API. The persistence package stays entirely behind that boundary. This preserves Laravel's architecture, isolates the license surface, and makes the exit path a matter of swapping an API client.
• Shared database (discouraged). Having Laravel read Ibexa tables directly couples your application to an internal schema that Ibexa explicitly does not treat as a public contract. Expect silent breakage on every DXP upgrade.

If the underlying need is simply "a robust repository abstraction over Doctrine DBAL," use Doctrine DBAL directly. It is MIT-licensed, has a large support base, and does not require adopting a DXP.

Migration path. If a pilot is warranted, scope it as a platform evaluation rather than a dependency trial: stand up Ibexa DXP (or its trial), model two or three real content types, expose them via GraphQL, and have a Laravel service read and render them. Timebox to four to six weeks with a written go/no-go gate at the end. Do not begin by adding this package to composer.json in an existing Laravel application — that path produces integration debris and no usable signal.

Compatibility. Expect version friction at the Composer level: conflicting Symfony majors, Doctrine DBAL majors, and PSR implementations between the Ibexa stack and a modern Laravel install. In the sidecar model this friction disappears, because the two applications share nothing but an HTTP contract. Confirm the PHP version matrix against your platform baseline (Ibexa's supported PHP range typically trails the newest Laravel requirements).

Sequencing.

1. Legal and license review — hard gate. Resolve BUL vs. GPL-2.0 and distribution scope before engineering effort.
2. Confirm the need — content management platform, or generic persistence? Route accordingly.
3. Commercial step — if platform, procure the DXP subscription; the BUL path is the only viable one for a distributed product.
4. Sidecar POC — API-only integration, no shared code.
5. Contract tests — pin and test the API surface you consume so DXP upgrades surface as test failures rather than production incidents.
6. Decision gate — cost of ownership vs. a Laravel-native or headless alternative.

Operational Impact

Maintenance. Release cadence is dictated by Ibexa's DXP release train, not by your roadmap. The package moves with the monorepo, so its changelog is only meaningful in the context of a platform upgrade. Major DXP versions have historically required content migration work; budget for that as a recurring, non-optional cost. Subscribers get vendor patches and security advisories; GPL users rely on community channels that, at three stars and zero dependents, are effectively empty.

Support. There is no community safety net. The only credible escalation path is a commercial contract. Internally, expect near-zero existing expertise: Ibexa/eZ Platform is a niche skill market, and contractor rates and lead times reflect that. Any key-person dependency here is a material risk.

Scaling. The persistence layer is built for large content repositories on MySQL/MariaDB and will scale further than most teams need. But the baseline operational footprint is heavier than a Laravel application's — you are running and tuning a full DXP, not a library. Note also that core-persistence is storage only: search, caching, and HTTP delivery are separate components. Adopting this package does not give you a content platform; it gives you the bottom slice of one.

Failure modes to plan for:

• License audit block — the most likely failure, and the cheapest to detect early. NOASSERTION will fail CI policy gates.
• Dependency deadlock — conflicting Symfony/Doctrine majors between the Ibexa stack and your Laravel app, if you attempt co-installation.
• Schema drift — silent breakage if anything outside Ibexa writes to its tables.
• Unpatched vulnerabilities — forking or pinning without a subscription means no security feed.
• Abandoned integration — low adoption means no third-party ecosystem to lean on if Ibexa changes direction.

Ramp-up. High. Allow four to eight weeks before an engineer is independently productive with Ibexa's SPI, content model, and migration tooling — and accept that very little of that knowledge transfers back to Laravel work. The POC should be budgeted as exploratory with a genuinely open outcome; on current evidence, the most probable and least expensive conclusion is to decline the package and address the underlying requirement with a Laravel-native or API-first alternative.