Sonata Elastica Bundle Laravel Package

Product Decisions This Supports

• Stack-fit gate (decide this first): This is a PHP package, but it is not a Laravel package. It is a Symfony bundle that plugs Elasticsearch (via the Elastica client) into Sonata Admin's list view, datagrid, and filters. If our back-office runs on Laravel Nova, Filament, Backpack, or a custom Laravel admin, the answer is "out of scope" before any other evaluation happens. The first PM output is simply confirming which stack our admin surface uses.
• Build vs. buy vs. borrow: MIT makes "buy" free, but the repo is archived, with 43 stars and 0 dependents. That reframes the decision from "adopt a dependency" to "borrow a reference implementation": read the data-provider/filter wiring, then build or fork our own. Adopting an archived bundle into a production admin path is a maintenance liability, not a shortcut.
• Roadmap bet: back-office performance at scale. The capability it proves — serving admin list screens and multi-criteria filters from an Elasticsearch index instead of the primary database — is a legitimate roadmap item when ops users hit slow, unindexed, join-heavy list views over large tables. This package is evidence the pattern is viable; it is not evidence that it is maintained.
• Use cases worth scoping: high-row-count admin grids, faceted filtering across several criteria, dashboards where DB read load competes with customer-facing traffic, and internal tooling where a few hundred milliseconds of list latency materially affects operator throughput.
• Explicit non-use cases: any Laravel admin panel; any environment requiring active security patching or vendor support; any stack already on Elasticsearch 8+/OpenSearch where this bundle's Elastica-era assumptions are stale; any procurement or compliance review that rejects unmaintained dependencies.
• Risk register and TCO input: archived status plus zero dependents means no upstream fixes, no CVE response, and no community to lean on. The decision record should state plainly that total cost of ownership includes owning the fork, not just the integration spike.
• Sequencing decision it informs: whether to (a) build a Laravel-native Elasticsearch read path (custom repository returning a LengthAwarePaginator, with model events syncing documents), (b) stand up a Symfony sidecar admin, or (c) copy patterns from this bundle under MIT. The package primarily informs option (c).

When to Consider This Package

Consider it when all of the following hold:

• The back-office is Symfony + Sonata Admin — this bundle has no Laravel integration path.
• We already run an Elasticsearch/Elastica version matching the bundle's pinned dependencies, verified by reading composer.json, not assumed.
• The need is genuinely read-path acceleration for admin lists and filters, not new end-user search functionality.
• We are willing to treat it as fork-and-own or copy-the-pattern, with a named engineer accountable and a documented upgrade path.
• A timeboxed spike (1–2 weeks) is demonstrably cheaper than writing a custom Sonata datagrid/provider from scratch, and the spike is scoped to prove that out.

Look elsewhere when any of the following hold:

• The stack is Laravel. Stop here. Evaluate Filament/Nova integrations, the official Elasticsearch PHP client behind a custom query layer, or Laravel Scout-style abstractions instead.
• Maintenance and security posture matter — nearly always true for anything touching production data. Archived repos get no patches; plan for a fork or a maintained alternative.
• A maintained Symfony alternative exists (actively released Sonata/Elasticsearch integrations, or a thin custom provider over the official Elasticsearch PHP client). A maintained generic client usually beats an archived purpose-built bundle.
• Elasticsearch is 8+/OpenSearch and dependency pins block it — cost shifts from integration to migration, and build-vs-borrow math changes.
• The team lacks Symfony/Sonata or Elasticsearch operational depth. Running a cluster to speed up an admin grid carries standing costs — indexing pipeline, mapping changes, reindex jobs, DB-to-index drift — that outweigh the latency win on small datasets.
• The dataset is small or queries are already fast. Below the point where list queries dominate admin latency, an index is pure overhead.

How to Pitch It (Stakeholders)

One-line summary: A small, MIT-licensed Symfony bundle that makes Sonata Admin list screens and filters fast by serving them from Elasticsearch — useful as a proven pattern, but archived, low-adoption, and not Laravel-compatible, so we recommend borrowing the approach rather than adopting the dependency.

For executives: The business value is operator throughput on large back-office screens — faster lists and filters mean less waiting and less database contention with customer-facing traffic. The cost of trying it is near zero (MIT, small surface area), but the cost of depending on it is not: the project is archived, has 43 stars and zero dependents, and will receive no updates or security fixes. This is a low-cost experiment with a capped downside, not a platform commitment. Fund a short, timeboxed spike; do not add it to the production dependency list without an owner for a fork.

For engineering: Treat this as a reference implementation, not a dependency. Read how it wires Elasticsearch into Sonata's list/filter pipeline, then choose between (a) forking and owning it, or (b) a thin custom data provider over the official Elasticsearch PHP client — and in a Laravel shop, (b) is almost always the right answer since a Symfony sidecar means a second deployable, a second auth model, and a duplicate domain model. Before either path, verify three things: our admin stack is actually Symfony/Sonata, the pinned Elastica/ES versions match our cluster, and we accept the indexing-pipeline operational load — mapping changes, reindexing, and DB-to-index drift. Note the package only solves the read-path UI; the hard scaling problem moves to the sync path (outbox, queue depth, reindex windows), which it does nothing to address. Any adoption proposal must include a named maintainer, a fork policy, and a migration exit plan.

Decision requested: Approve a 1–2 week spike to validate the pattern on our admin stack, with the default outcome being pattern reuse, not dependency adoption — unless the spike shows the fork cost is lower than building it ourselves.