Laravel Mysql Spatial Laravel Package

Technical Evaluation

Architecture fit

• Unchanged by 5.0.0. The package remains a thin, well-scoped extension of three Laravel seams: the schema Blueprint (point(), polygon(), geometrycollection() column types), the query builder (whereDistance, whereWithin, whereContains, orderByDistance), and Eloquent attribute casting (spatial columns hydrate into typed value objects rather than raw WKT/WKB).
• No service-boundary or infrastructure footprint: it is a library, not a daemon or sidecar, and it does not change how the app connects to MySQL. It slots into an existing monolith/modular Laravel codebase without architectural negotiation.
• The architectural value is containment: without it, geospatial logic leaks into controllers as DB::raw('ST_GeomFromText(...)') and ST_Distance_Sphere string expressions, which are untestable and untyped. With it, the domain gets Point/Polygon value objects and the spatial predicate vocabulary is expressed once.
• Fit remains conditional on MySQL being the system of record for the geometry. If geometry lives in PostGIS, or the roadmap points to multi-store, this package is a dead end and should not be adopted.

Integration feasibility

• The 5.0.0 release note — "Support for Laravel 8 with MySQL 5.7" — is the single most consequential new fact, and it cuts both ways. It confirms the framework floor and ceiling: Laravel 8 is the newest supported version. Laravel 9/10/11 remain unsupported, so the compatibility-spike requirement in the prior assessment stands unchanged for any team on a current Laravel.
• It also confirms a database ceiling. MySQL 5.7 is the only declared MySQL target. MySQL 8.0 — the version with SRID-tagged geometry and latitude-first axis-order semantics — is not declared, which means the most dangerous behavior in this package's surface area is explicitly outside its tested matrix. Previously this was an open question; now it is a known gap you must close yourself.
• The declared support matrix is entirely end-of-life: Laravel 8 security support ended January 2023, PHP 7.4 reached EOL in November 2022, and MySQL 5.7 reached EOL in October 2023. Adopting 5.0.0 means adopting a package whose only supported platform no longer has vendor support. That is not disqualifying in a Laravel 8 estate that is itself frozen, but it is disqualifying as a forward-looking choice for a team on Laravel 10/11.
• 5.0.0 is a major version bump, which by semver signals breaking changes relative to 4.x. Before pinning, read the changelog and the 4.x→5.0.0 diff for: namespace or cast-class renames, value-object constructor signature changes, a bumped geometry dependency (the brick/geo-style library), changed illuminate/* and PHP constraints, and any migration-grammar changes. Any prior 4.x PoC code must be re-validated, not merely re-pinned.
• Re-verify the license on the new tag. The repository metadata previously reported NOASSERTION; a major release is a plausible moment for an accidental or deliberate relicense, and legal clearance is still a hard gate.
• Install and first use remain cheap: one Composer dependency, one service provider, migrations and casts work immediately. A single-table PoC is still a 1–2 day effort.

Technical risk

• Abandonment (downgraded from highest, still high). A release after roughly five years is a heartbeat, not a cadence. It materially improves the odds that a security or compatibility patch would be accepted upstream, and it justifies switching from "assume dead" to "adopt-and-pin with a named owner." It does not justify treating this as a maintained dependency: one release, one maintainer, and no published support policy.
• Silent correctness failure (now the highest risk). With the declared database target being MySQL 5.7, the package has not asserted anything about MySQL 8 SRID semantics or axis-order behavior for SRID 4326 geometries. The failure mode is data that passes every schema check and renders plausibly while being mirrored across the globe. This risk is unchanged in magnitude and now has a documented reason to expect it. It needs a named owner and a golden-dataset test, not a code review.
• Engine divergence. MySQL 5.7 and 8.0 differ on ST_Distance_Sphere SRID preconditions and on whether geometries carry an SRID at all; MariaDB implements a different ST_* surface. Any portability claim must be proven on your actual target version.
• Spatial index constraints. SPATIAL INDEX requires NOT NULL columns and an appropriate InnoDB version; naive adoption produces table scans that only appear under production data volume. Validate with EXPLAIN, never assume.
• Upgrade-treadmill risk. If 5.0.0 turns out to be a one-off rather than the start of a cadence, you are now pinned to a version with no successor path and no 4.x security backline.

Key questions

1. What changed between 4.x and 5.0.0, and is the diff limited to framework/DB constraint widening or does it touch the public API and the geometry dependency?
2. Is 5.0.0 the start of a release cadence, or a single compatibility patch? Ask the maintainer directly; the answer determines fork urgency.
3. What is the exact MySQL flavor, version, and SRID convention in production, and who owns geodesy correctness — particularly if that version is 8.0, which the package does not claim to support?
4. Which Laravel and PHP versions must be supported at ship date, and at +18 months? If the answer is Laravel 10/11, this package is out of scope regardless of the new release.
5. Is the workload read-heavy bounding-box filtering, or do we need write-path geometry validation and complex topology predicates?
6. Who forks it when it breaks, and what is the accepted lead time for that patch?
7. Has legal cleared the NOASSERTION license status on the 5.0.0 tag specifically?
8. Is PostGIS on the table? If yes, stop and re-evaluate, because this package buys a MySQL-only dead end.

Integration Approach

Stack fit

• Green, as of 5.0.0, on Laravel 8 + PHP 7.4/8.0 + MySQL 5.7 — with the caveat that this is a fully end-of-life stack and is only appropriate for an estate already frozen there.
• Yellow on MySQL 8.0: the combination is untested by the maintainer and must be validated in-house, with the SRID/axis-order tests written by you.
• Red on Laravel 9/10/11. The doctrine/dbal schema path remains the likely break point, and the new release does not move that needle at all.
• Fit is best in a conventional Eloquent-centric codebase with a single MySQL primary. It fits poorly where raw spatial SQL is already used deliberately, or where database-agnostic schema definitions are required — SQLite test suites will not support these column types, so CI must run against real MySQL or the spatial tests must be isolated.

Migration path

• If a 4.x prototype exists, treat 5.0.0 as a mini-migration rather than a version bump: read the changelog, re-run the conformance suite, and expect at minimum constraint changes and possibly cast/value-object renames. Do not assume drop-in.
• Adopt incrementally and never rewrite existing geometry storage in the same release. Phase 1: new tables only, using the package's column types and casts. Phase 2: introduce query helpers behind a repository or query-object layer. Phase 3: optionally backfill legacy WKT/WKB columns via ST_GeomFromText migrations — always nullable-first, backfill, then NOT NULL and index; never add a SPATIAL INDEX and a backfill in one migration on a large table.
• Wrap all spatial predicates behind an internal interface from day one. The purpose is not elegance; it is making a swap to matanyadaev/laravel-eloquent-spatial, raw ST_* expressions, or a PostGIS adapter a bounded, single-package change rather than a codebase-wide grep.
• For any further constraint widening, prefer a pinned VCS fork or a replace directive over an unpinned dev-branch dependency. Never point production at dev-master of an unmaintained single-maintainer repository.

Compatibility

• Pin exact versions and lock the database image in CI. The matrix is now two-part: the declared path (Laravel 8, MySQL 5.7) as a regression baseline, plus your actual production path (likely MySQL 8.0, and whatever Laravel version you are truly on) as an explicit, owned risk.
• Explicitly test: coordinate round-trip preserves axis order for SRID 4326; orderByDistance results are geodesic and monotonically sane at the equator, poles, and across the antimeridian; EXPLAIN shows the spatial index is used for whereWithin at target dataset size; and the same geometry read back on 5.7 and 8.0 produces identical coordinates.
• Do not assume MariaDB parity. If MariaDB is in the fleet, budget a separate verification pass or explicitly exclude it.

Sequencing

1. Legal review of the license (NOASSERTION) against the 5.0.0 tag — cheap, blocks everything, do it first.
2. Read the 5.0.0 changelog and 4.x→5.0.0 diff; produce a written delta of API and dependency changes. Half a day.
3. Compatibility spike on a throwaway branch: install 5.0.0 on your target Laravel, run a migration with a point column, run one distance query. Timebox to 2 days; the outcome is a Go/No-Go with a concrete patch list.
4. Decide fork-and-own vs. adopt-and-pin. The new release slightly improves the case for adopt-and-pin; if the maintainer confirms no cadence, establish the fork before product code depends on the original.
5. PoC on one non-critical table with EXPLAIN and latency benchmarks at realistic row counts.
6. Widen to remaining tables one release at a time, with the conformance suite growing alongside.
7. Publish the exit-path document before general availability, not after the first incident.

Operational Impact

Maintenance

• This remains an ownership transfer, not a subscription. Budget roughly 2–4 engineer-days per year for dependency bumps, PHP/Laravel compatibility patches, and the CI matrix. The 5.0.0 release does not reduce that budget; it confirms the shape of the work (someone upstream widening constraints) while leaving the verification burden with you. Assign a named owner.
• Because there is no release cadence, security patching for this dependency is manual. It must appear in the SBOM and in dependency review, or it will silently rot — a single release is not a substitute for a patch process.
• Track upstream issue activity for a quarter after adopting 5.0.0. Sustained responsiveness changes the fork calculus; silence reverts the assessment to the prior "assume abandoned" position.

Support

• No vendor, no SLA, no committed issue triage. Support is internal: a runbook covering spatial index creation, SRID conventions, MySQL 5.7 vs 8.0 behavior differences, and the fork's release process. Onboarding docs matter more here than for a healthy dependency, because the institutional knowledge is entirely in-house.
• The team will field questions the package cannot answer — geodesic vs. planar distance, axis order, polar edge cases. Plan for one person to hold that knowledge.

Scaling

• SPATIAL INDEX gives R-tree bounding-box filtering, which is excellent for "within this viewport / this radius" queries at scale. Distance ordering and filtering are not indexable in the general case: always prefilter with a bounding-box predicate (whereWithin) before orderByDistance, or a millisecond index scan becomes a full scan with per-row trigonometry.
• Watch write amplification: geometry columns inflate row size and index size, and high-precision polygons bloat the R-tree. Establish a precision/rounding policy (e.g. 6–7 decimal places) at the schema level.
• Read replicas are safe, but index behavior must be validated on replica-typical data volumes, not dev-sized datasets.

Failure modes

• Silent geospatial corruption — axis-order or SRID mismatch produces valid-looking but mirrored coordinates. Given that the declared target is MySQL 5.7, this is the most probable failure on a MySQL 8.0 deployment. Mitigation: golden-dataset conformance tests and a coordinate assertion in the write path.
• Stale-platform lock-in — the package's supported matrix (Laravel 8, PHP 7.4, MySQL 5.7) is fully end-of-life, so you are running an unsupported configuration even on the vendor-blessed path. Mitigation: treat the framework/database upgrade as the trigger for an exit to a maintained alternative, and write that trigger into the exit-path doc with a date.
• Schema operations throw at the worst time — ->change() or a column alteration on a spatial column fails due to doctrine/dbal handling in the migration path. Mitigation: rehearse destructive migrations on a production-sized snapshot.
• Upgrade breakage mid-quarter — a Laravel or PHP minor forces an emergency fork patch. Mitigation: the fork exists before it is needed, and CI runs the target matrix nightly.
• One-off release false comfort — 5.0.0 creates the impression of an active project. Mitigation: measure against cadence, not against a single tag; re-evaluate if no further release lands within two quarters.
• Database minor-version drift — a managed MySQL minor upgrade changes ST_* behavior. Mitigation: pin the engine version where the provider allows, and include a post-upgrade spatial smoke test in change management.

Ramp-up

• Basic usage — adding a column, casting to a point, running a radius query — remains a one-day learning curve for anyone fluent in Laravel. The API is small and conventional, and 5.0.0 does not change that.
• Geodesy correctness is the real ramp: planar vs. spherical distance, SRID semantics, WKT/WKB axis order, and when an R-tree index does and does not help are not things the package teaches. Budget one senior engineer to own it and review every spatial migration.
• Net assessment: 5.0.0 moves this from "adopt only as a fork" to "acceptable as a pinned, internally-owned dependency" for MySQL-backed Laravel 8 products where geometry is a supporting feature — but it does nothing for Laravel 9+, nothing for MySQL 8.0 confidence, and nothing about the EOL platform. Still not acceptable as an unexamined transitive dependency on a critical path, and still the wrong choice if PostGIS or polyglot persistence is plausible within the planning horizon.