Laravel Spanner Laravel Package

Product Decisions This Supports

• Database platform choice for Laravel services. Adopting this driver is the practical enabler for running an existing Laravel/Eloquent codebase on Google Cloud Spanner instead of Cloud SQL, Aurora, or Postgres — it lets you evaluate Spanner's global consistency and horizontal scale without rewriting the data layer.
• Build vs. buy (buy = adopt OSS). Writing an in-house Spanner driver means owning session/read-your-writes semantics, DDL translation, schema builder, and transaction retry logic. This package collapses that into a dependency, so the real decision is "Spanner or not," not "this package or not."
• Read-consistency and isolation posture per service. v12.0.0 makes isolation_level configurable (feat: allow isolation_level to be set in config). That turns transaction isolation from a hardcoded assumption into a per-service configuration decision — relevant when moving a Postgres-dialect workload to Spanner, where REPEATABLE_READ vs SERIALIZABLE has direct bearing on contention, retry rates, and read throughput.
• Test and CI infrastructure strategy. The clear session when dropping a database change — carried into the stable v12.0.0 — directly supports harnesses that create and tear down ephemeral Spanner databases per test run. That matters if the roadmap includes per-PR integration environments or parallel test shards; it is the failure mode that otherwise makes those harnesses flaky.
• Migration sequencing. If a service is moving off MySQL/Postgres, the driver's Eloquent/query-builder coverage defines how much application code survives the move versus how much gets rewritten against raw gRPC. The v12.0.0 index-name fix (indexes with ORDER BY) matters here specifically: migrations that already produce correctly-shaped indexes previously produced mis-named ones, so teams with existing Spanner schemas should treat this as a possible correction step, not a no-op.
• Framework upgrade planning. v12.0.0 is now a stable major release, not a beta. It sets a floor on supported Laravel/PHP versions and on the Google Cloud Spanner client — feat: cloud spanner v2 moves the driver onto the v2 client library. That double floor feeds directly into how the platform team sequences Laravel and GCP SDK upgrades across the fleet.
• Unit economics of high-read workloads. The v12.0.0 performance work (single LIKE check per query in the parameterizer; timestamp timezone conversion moved before Carbon instantiation) reduces per-query and per-row overhead. On Spanner, where cost is driven by processing units and CPU, per-row overhead is a TCO line item — this weakens the "the driver itself is too slow for high-volume paths" objection.
• Multi-tenant and high-write product bets. Spanner's interleaved tables and strong consistency are attractive for tenant-partitioned data models; the driver's maturity bounds how confidently you can commit to those designs.

When to Consider This Package

Adopt when:

• Spanner is already the chosen datastore (organizationally or by mandate), and the team wants Eloquent, migrations, and the query builder rather than hand-rolled gRPC clients.
• You need schema migrations managed inside Laravel rather than by a separate DDL pipeline — including indexes with ORDER BY, now handled correctly.
• Session consistency semantics (read-your-writes after a write within a request) are required and you don't want to reimplement them per service.
• You want transaction isolation to be a configuration concern rather than a code change, e.g. tuning isolation_level per service or per environment.
• You can take a stable v12.0.0 rather than a pre-release — this release clears the "pin to an exact beta tag" caveat. Still pin to an exact tag; v11 → v12 is a major bump with breaking changes, and the release notes do not enumerate them.

Look elsewhere when:

• Spanner is not already decided. This driver is not a reason to pick Spanner; it is a cost reducer once Spanner is picked.
• Vendor neutrality or multi-cloud portability is a hard requirement.
• The workload is small or cost-sensitive — Spanner's minimum provisioned capacity dominates the TCO long before driver concerns do.
• You require commercial support, an SLA, or a large contributor base; this is a community-maintained package, and stability of the release line does not change that.
• You're on an older Laravel/PHP combination outside the v12 support window, or pinned to the v1 Cloud Spanner client and can't move to v2 — check the repo's upgrade notes for the exact floors, since the major bump plus the client-library bump is a compound upgrade.
• Your production schema already contains indexes defined with ORDER BY and you cannot verify whether they were created with correct names — validate before upgrading rather than discovering it at query time.

How to Pitch It (Stakeholders)

For executives: This is the piece that lets our existing Laravel applications run on Google Cloud Spanner without a bespoke data-access layer or a dedicated driver team, and as of v12.0.0 it is a stable major release rather than a beta — one of the two risks we previously flagged is now retired. The remaining risk is support: it is community-maintained with no commercial backing or SLA. Recommended posture is to run a pilot, keep Spanner optional at the architecture level, and size Spanner's baseline capacity cost, which remains the larger financial commitment by far. The release also lands performance and correctness fixes that reduce the cost of high-volume read paths and make ephemeral per-PR test databases viable.

For engineering: v12.0.0 is the stable cut of the major line: Eloquent, query builder, schema builder, and migrations, with request-scoped session handling for read-your-writes. Three things to plan around. First, it moves onto the Cloud Spanner v2 client — budget that as a compound upgrade alongside the Laravel/PHP version floor. Second, isolation_level is now configurable, so decide deliberately per service rather than inheriting a default. Third, the index-name fix for ORDER BY indexes may change what migrations emit; diff generated DDL against existing production schemas before rolling forward. The session-clearing fix on database drop is in this release, which is what makes a per-PR Spanner CI harness non-flaky. Performance-wise, LIKE checks are hoisted to once per query and timestamp timezone conversion no longer runs per row through Carbon. Before adoption: confirm the Laravel/PHP/client floors against upgrade notes, run our integration suite against a dedicated GCP project, and check how the driver surfaces Spanner's transaction-abort retries so we don't inherit silent retry gaps in write-heavy paths.