I Tried to Run Google's Most Enterprise Database on My MacBook. Here's What Actually Happened.

Ishant gupta — Wed, 29 Apr 2026 13:57:01 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

At Google Cloud NEXT '26, buried inside announcement #68 of 260 total announcements, was a single sentence that stopped me cold:

"Run it anywhere — across multiple clouds, on-premises, or on your laptop."

"It" is Google Spanner — the database that powers Gmail, Google Ads, Google Pay, and YouTube. The system Walmart, Goldman Sachs, and Shopify depend on for their most critical workloads.

They said I could run it on my laptop. So I tried. Here's the honest account of what happened — including the part where Google locked me out before I even started.

Spoiler: Spanner Omni itself requires whitelisting. But what I could run locally surprised me more than I expected.

What Spanner Omni Actually Is

Spanner Omni is Google's answer to a question nobody thought they'd ask: what if you could take the database that runs Google's entire ad business and make it deployable anywhere — on AWS, on-premises, in an air-gapped data center, or on a developer's MacBook?

The hard engineering problem wasn't the database itself. It was TrueTime.

Original Spanner's legendary consistency guarantees depend on atomic clocks and GPS hardware physically embedded inside Google's data centers. That hardware is what lets Spanner know, with mathematical certainty, the order in which transactions happened across data centers on opposite sides of the planet.

You cannot ship GPS satellites in a Docker image.

So Google built a software-defined TrueTime alternative — a reimplementation that provides error-bounded time synchronization without specialized hardware, relying on the insight that Spanner can tolerate weaker uncertainty bounds because it overlaps time-uncertainty waits with other database work.

That is not a minor detail. That's a fundamental reimagining of one of distributed systems' most famous components, shipped quietly alongside 259 other announcements.

The Part Google Didn't Advertise: It's Not Public Yet

The blog post says "available today in preview." What it doesn't prominently say: the Docker image requires Google to whitelist your account before you can pull it.

I found this out the hard way:

docker pull us-docker.pkg.dev/cloud-spanner-omni-preview/release/spanner-omni:2026.r1-beta

Even after configuring gcloud auth, the pull failed with the same authorization error: permission denied on the registry. The preview is real, but access is controlled. If you want in, you need to contact Google directly.

This is worth knowing before you block off an evening.

What You Can Do Right Now: The Spanner Emulator

While Spanner Omni stays behind Google's velvet rope, there's a fully functional local Spanner environment that IS publicly available right now: the Cloud Spanner Emulator.

docker pull gcr.io/cloud-spanner-emulator/emulator

docker run -d -p 9010:9010 -p 9020:9020 \
  --name spanner-emulator \
  gcr.io/cloud-spanner-emulator/emulator

It pulled cleanly and started in under 2 seconds:

Configure gcloud to point to your local emulator:

gcloud config set auth/disable_credentials true
gcloud config set project test-project
gcloud config set api_endpoint_overrides/spanner http://localhost:9020/

Then run a real query:

gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT 'Spanner is running on my MacBook' AS message"

That line printing in my terminal felt genuinely surreal. This is the same database engine that handles Google's global ad auction, running entirely offline on a MacBook Air.

Benchmark: How Fast Is It Locally?

I didn't just want to run a hello-world query. I wanted real numbers.

I inserted 1,000 rows using a shell loop:

for i in $(seq 1 1000); do
  gcloud spanner rows insert \
    --instance=test-instance \
    --database=test-db \
    --table=Users \
    --data="UserId=$i,Name=User$i,Email=user$i@test.com"
done

Then timed a COUNT query across all 1,000 rows:

time gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT COUNT(*) FROM Users"

And a LIMIT 100 fetch:

time gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT * FROM Users LIMIT 100"

Result: 100 rows fetched in 0.37 seconds on a MacBook Air. COUNT across 1,000 rows returned near-instantly. For a database engine designed for planet-scale distributed workloads, that's more than responsive enough for real local development.

ACID Transactions Working Locally

This is Spanner's actual superpower — strong consistency across distributed nodes. I wanted to verify it works locally too.

gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="UPDATE Users SET Name = 'Ishant Gupta' WHERE UserId = 1" \
  --enable-partitioned-dml

Immediately queried it back:

gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT * FROM Users WHERE UserId = 1"

The change was there instantly. Then I ran aggregations across all 1,000 rows:

gcloud spanner databases execute-sql test-db \
  --instance=test-instance \
  --sql="SELECT COUNT(*) as TotalUsers, 
        MAX(UserId) as MaxId, MIN(UserId) as MinId 
        FROM Users"

COUNT, MAX, MIN — all correct, all returned in under a second. This isn't a mock. It's real Spanner consistency semantics running entirely offline.

Vector Search: The AI Angle

One of the biggest NEXT '26 announcements was Spanner's support for vector search — making it viable as an AI retrieval database with no ETL pipeline needed.

I created the schema locally to see if the emulator would accept it:

CREATE TABLE Documents (
  DocId INT64 NOT NULL,
  Content STRING(MAX),
  Embedding ARRAY<FLOAT32>
) PRIMARY KEY (DocId)

It accepted the schema instantly. Note: actual vector similarity search queries require cloud Spanner — but designing and validating your AI data model locally before touching production is exactly the workflow Google is targeting with these announcements.

The Real Story: Solving the Parity Problem

Here's what I think is genuinely underreported about both the emulator and Spanner Omni:

Before this, building on Spanner meant one of three painful options:

Mocking the database (fast but inaccurate)
Substituting SQLite (wrong SQL dialect, wrong behavior)
Pushing every change to a cloud dev environment and waiting

With a local Spanner running, the queries that work in your terminal work in production. The schema you design locally is the schema you deploy. The ACID semantics you rely on locally are the semantics you get in prod.

For AI applications specifically, this matters even more. Spanner now supports vector search, Spanner Graph for relationship queries, and full-text search — all in one database. You can prototype an entire AI retrieval stack locally, for free, before spending a rupee on cloud credits.

My Honest Take

Spanner Omni as announced is not what you can run today unless Google whitelists you. That gap between the blog post and actual access is worth calling out — not as a criticism, but as something every developer should know before they try.

But the emulator is real, it works, and the numbers speak for themselves: 1,000 rows, 0.37 second fetches, real ACID transactions, and vector-ready schema — all running on a MacBook Air that was also playing Spotify.

The 2012 Spanner paper felt like reading about infrastructure from another planet. Running SELECT * FROM Users locally in 2026 means that planet is now your dev environment.

If you're building anything data-intensive — especially with AI retrieval — run these two Docker commands this weekend and see how it fits your stack. I'm waiting on Spanner Omni access; when it lands, I'll write the follow-up this article deserves.

References:

DEV Community: Ishant gupta