DEV Community: Ishant gupta

Git-regret 💀 — I Finally Finished the CLI That Reads Your Shame

Ishant gupta — Tue, 02 Jun 2026 08:31:21 +0000

This is an official submission for the GitHub Finish-Up-A-Thon Challenge.

Try It Yourself: https://ishantgupta30.github.io/git-regret/

🕒 Introduction: The Ghost in the `.git` Directory

Every developer has a digital graveyard.

It is a hidden directory, usually tucked away in a generic /Developer/Projects folder, filled with half-baked ideas, abandoned repositories, and code that was written at 3:00 AM under the influence of intense caffeine and false confidence.

For 18 months, my personal digital graveyard contained a repository called git-audit-tool.

If you opened that repository and ran git log, you would find a brief, tragic story told in three commits:

initial commit - hackathon night
wip add secret detection - crashes on big repos
giving up for tonight, too tired - will finish later

That last commit sat there untouched for a year and a half.

The code inside was embarrassing.

It was a single Python file that hardcoded execution limits, contained broken placeholders, and regularly threw unhandled exceptions if you pointed it at a repository with a mature history.

But the core problem never went away:

Nobody actually checks their git history until something goes terribly wrong.

We push API keys.

We squash terrible commit messages into production branches.

We leave panic-driven fix: layout again commits scattered across our history.

When the GitHub Finish-Up-A-Thon was announced, I realized it was time to stop closing the tab.

It was time to take this broken, abandoned script and turn it into a production-ready CLI.

This is the story of how I completely rewrote that technical mess into git-regret—a tool that scans repository history for mistakes, calculates project "regret metrics," and generates GitHub Copilot remediation plans automatically.

🛑 The Before: One Function, Zero Architecture, Infinite Shame

Before discussing the rebuild, we need to look at the starting line.

The original script was a masterclass in anti-patterns.

One file
Zero tests
Fragile parsing
Hardcoded limits
Empty TODOs everywhere

import subprocess
import sys

# wip - trying to add secret detection
# TODO: this crashes on big repos lol

def run_audit(path="."):
    result = subprocess.run(
        ["git", "log", "--oneline", "-20"],
        cwd=path,
        capture_output=True,
        text=True
    )

    if result.returncode != 0:
        print("not a git repo")
        return

    commits = result.stdout.strip().splitlines()
    print(f"checking {len(commits)} commits...")

    for line in commits:
        sha = line.split()[0]
        msg = " ".join(line.split()[1:])

        if "wip" in msg.lower():
            print(f"bad commit: {sha} — {msg}")

if __name__ == "__main__":
    path = sys.argv[1] if len(sys.argv) > 1 else "."
    run_audit(path)

🔍 Anatomy of a Broken Script

The Magic Number Limitation

["git", "log", "--oneline", "-20"]

The tool literally refused to inspect more than 20 commits.

Fragile String Parsing

sha = line.split()[0]

The parser assumed every log line would always have the same structure.

Not exactly resilient engineering.

The Phantom Feature

The tool claimed to perform secret detection.

The implementation?

# TODO secret detection here

The README

# git-audit-tool

TODO: write this.

## Status
Gave up. Crashes on any repo > 10 commits. Will fix later.

- [ ] fix the crash
- [ ] add secret detection
- [ ] make it actually useful

Every time I looked at the repository, the technical debt felt bigger than the project itself.

💡 Designing git-regret

To build a utility people would actually use, I had to stop thinking like a script writer and start thinking like a systems engineer.

The vision centered around three pillars:

1️⃣ Multi-Dimensional Analysis

[Repository Scan Engine]
       │
       ├── HIGH SEVERITY 🚨
       │      ├── Secret Leaks
       │      └── Fix Chains
       │
       └── MEDIUM SEVERITY ⚠️
              ├── WIP Commits
              ├── Regret Keywords
              └── Giant Commits

2️⃣ Decoupled Architecture

Analysis and presentation should never depend on one another.

3️⃣ AI-Powered Remediation

Finding mistakes is useful.

Generating the exact fix plan is even better.

This became the foundation of the --copilot feature.

🤖 Pairing with GitHub Copilot

A surprising amount of CLI development is boilerplate:

Regex creation
Test fixtures
Argument parsing
State tracking

GitHub Copilot helped accelerate all of it.

🧠 Challenge #1: Secret Detection

I needed a reliable set of patterns for identifying leaked credentials.

Prompt

I am building a high-performance Python static analysis tool for git history. Generate compiled regex patterns for AWS keys, Stripe live keys, GitHub tokens, private SSH keys, database URLs, and common API secret assignments.

Result

import re

SECRET_PATTERNS = {
    "aws_access_key": re.compile(r"AKIA[A-Z0-9]{16}", re.IGNORECASE),
    "stripe_live_key": re.compile(r"sk_live_[0-9a-zA-Z]{24}"),
    "github_pat": re.compile(r"ghp_[0-9a-zA-Z]{36}"),
    "pem_private_key": re.compile(r"-----BEGIN[A-Z ]+PRIVATE KEY-----"),
    "database_url": re.compile(
        r"(mongodb|postgresql|postgres)://[^:]+:[^@]+@[^/]+"
    ),
}

This became the foundation of the scanning engine.

⛓️ Challenge #2: Detecting Fix Chains

One common signal of rushed development is a series of consecutive patch commits:

fix: layout bug
fix: layout bug try 2
fix: forgot import
bugfix: typo

These should usually be squashed into a single commit.

I asked Copilot to generate a state machine capable of identifying runs of three or more consecutive fix commits.

The resulting implementation correctly handled edge cases and trailing chains without introducing off-by-one errors.

🧪 Challenge #3: Automated Testing

Testing Git tooling is difficult because you cannot safely mutate a real repository during unit tests.

I used Copilot to generate a Pytest fixture that:

Creates a temporary repository.
Configures dummy Git identities.
Generates synthetic commit histories.
Runs assertions against isolated repositories.

The result was a reproducible testing environment covering:

Secret detection
Empty histories
Pagination
Fix chains
WIP detection

By release day, the project had:

35 assertions
10 test scenarios
Full isolated execution

🏗️ Architecture

The rewrite introduced strict separation between components.

┌────────────────────────────┐
│ cli.py                     │
│ Flag parsing               │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│ analyzer.py                │
│ Repository analysis        │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│ ui.py                      │
│ Rich rendering + prompts   │
└────────────────────────────┘

This architecture makes the analysis engine reusable in:

GitHub Actions
CI systems
Future integrations

without modification.

🚀 The Result: git-regret

Installation:

pip install git-regret

Run:

git-regret

Sample output:

╭──────────────────────────────╮
│ git-regret 💀                │
│ Unbreak your past commits.   │
╰──────────────────────────────╯

Scanned 142 commits

Found:
🚨 1 HIGH
⚠️ 2 MEDIUM

[HIGH] Secret Leak Detected

Commit: a3f910d

Message:
hotfix: override api connection auth

Detail:
Leaked Stripe key detected

Suggested Fix:
Rotate credential and purge history.

🛠️ The Killer Feature: `--copilot`

git-regret --copilot

The tool generates a GitHub Copilot prompt tailored to the repository findings.

Example:

You are an elite principal engineer auditing my repository.

Detected:
- secret_leak
- trailing_fix_chain

Affected commits:
- a3f910d
- 84b2c11

Please:

1. Provide an interactive rebase plan.
2. Show git filter-repo commands.
3. Draft replacement commit messages.

Instead of searching Stack Overflow for hours, developers get an immediate remediation workflow.

📊 Before vs After

Metric	Old Script	git-regret
Codebase	87 Lines	520+ Lines
Architecture	Single File	Modular
Testing	None	35 Assertions
Analysis Rules	1	5
UI	print()	Rich
Error Handling	Minimal	Robust
AI Integration	None	Copilot Prompts

🔮 Roadmap

Planned features include:

`git-regret install-hook`

Automatically install pre-commit protections.

`git-regret --ci`

Generate GitHub Actions workflows automatically.

`.gitregret.json`

Custom organizational rules and policies.

🏁 Conclusion

Finishing an abandoned project taught me something important:

An old idea is not necessarily a bad idea. Sometimes it is simply waiting for a better implementation.

The original project failed because it lacked structure.

By introducing:

Decoupled architecture
Automated testing
GitHub Copilot assistance
Clear design boundaries

I transformed a forgotten hackathon script into a production-ready developer tool.

If you have an abandoned repository sitting in your projects folder, this challenge is your sign to revisit it.

You might discover that the hardest part was simply finishing.

⚡ Audit Your Repository Today

# Install
pip install git-regret

# Generate a report and Copilot remediation plan
git-regret --copilot

🔗 Links

🌐 Documentation & Website: https://ishantgupta30.github.io/git-regret/
📦 GitHub Repository: https://github.com/ishantgupta30/git-regret

⚡ Get Started

pip install git-regret
git-regret --copilot

If git-regret helps you uncover a secret, clean up a fix chain, or finally understand what happened in your repository six months ago, consider giving the project a ⭐.

I Built a Space App That Gives You Real-Time Planetary Data — Powered by Gemma 4, No Backend

Ishant gupta — Mon, 11 May 2026 18:36:34 +0000

I Built a Retro Space Mission Control Powered by Gemma 4 — and It Talks Like a NASA Commander 🚀

What happens when you give an open-source AI model the keys to the solar system?

I've been obsessed with space since I was a kid. But every space app I found was either too boring (just static facts) or too complex (needs a PhD to use).

So I built Cosmos Explorer — a retro, terminal-aesthetic space mission control center that runs entirely in the browser, powered by Gemma 4.

🔗 Live Demo → cosmos-explorer-ishant.netlify.app
🔗 Github

No downloads. No installs. Just open it and feel like you're at NASA.

The Idea: What if space exploration felt alive?

Static facts are boring. I wanted something that reacted — that felt intelligent, cinematic, and immersive.

That's where Gemma 4 came in.

Instead of hardcoding descriptions, I let Gemma 4 generate real-time mission briefings, reveal hidden planetary secrets, narrate the night sky like a planetarium, and compare worlds with the insight of an actual scientist.

Gemma 4 isn't just a feature in this app. It's the soul of it.

What is Cosmos Explorer?

It's a 7-in-one space dashboard built as a single HTML file:

Module	What it does
🌍 Solar System	Animated real-physics orbits, click any planet
🤖 Mission Briefings	Gemma 4 generates NASA-style planet briefings
💡 Discovery Mode	Gemma 4 reveals obscure scientific secrets
🛰️ Satellites	Live mission data for Hubble, JWST, Voyager 1 & more
📡 ISS Tracker	Real orbital physics, updates every second
🔭 Sky CAM	Point your camera at the sky — Gemma 4 narrates it
⚖️ Planet Compare	Gemma 4 analyzes any two worlds side by side

Let me walk you through each one.

Feature 1: The Solar System — Click a Planet, Get a Mission Briefing

The moment you click a planet, Gemma 4 kicks in. No loading spinner for 5 seconds. Just instant, cinematic text that typewriters across the screen like a real mission computer.

Gemma's output for Saturn:

TARGET ACQUIRED: SATURN. Ring system spans 282,000 km yet only 10-100 
meters thick. Density lower than water — it would float. Enceladus moon 
sprays water geysers at 1,400 km/h. Titan has liquid methane lakes. 
145 moons confirmed.

This isn't hardcoded. Gemma 4 writes this fresh every time. I just gave it a persona:

callGemma(
  'You are a NASA mission commander. Cite specific instruments and missions 
   by exact name. Begin with TARGET ACQUIRED:. Be cinematic. 2-3 sentences maximum.',
  `Generate a mission briefing for ${planetName}`
)

That system prompt is doing a LOT of work. The model picks up on tone, format, and scientific precision instantly. That's the power of a 27B instruction-tuned model.

Feature 2: Discovery Mode — Secrets Gemma Reveals

Every planet has a Discovery Mode button. Press it, and Gemma 4 digs up something genuinely obscure — not the usual "Saturn has rings" stuff.

Real output for Saturn:

DISCOVERY: Saturn's rings are geologically young — only 10 to 100 million years old, formed when dinosaurs walked on Earth. Cassini measured ring mass and dust accumulation rates, shocking scientists who expected billion-year-old rings. The rings may disappear in 100 million years as Saturn's gravity pulls them inward.

I prompted it as a planetary scientist with access to mission data:

'You are a planetary scientist revealing a genuinely obscure fact. 
 Choose something highly specific. Cite missions, instruments, or datasets. 
 2-3 sentences. Begin with "DISCOVERY: "'

What I love here: Gemma 4 doesn't just recite Wikipedia. It connects facts. The dinosaur comparison? That's Gemma making an analogy on its own.

Feature 3: Sky CAM — Your Camera Becomes a Planetarium

This is the feature I'm most proud of.

Point your device camera at the sky (or just use the direction/tilt sliders), and Sky CAM overlays constellation lines in real time. But the real magic? Hit "GEMMA AI ANALYSIS" and watch this happen:

"Turn your gaze southward, where Orion strides across the winter sky — Betelgeuse blazing with the light of a star 700 times larger than our own Sun, a red supergiant in its final cosmic act. In 2019, Betelgeuse dimmed so dramatically that astronomers worldwide predicted imminent supernova — a reminder that even celestial constants can surprise us. The ancient Egyptians saw Orion as Osiris, god of death and resurrection, his belt stars aligned with the three pyramids of Giza."

I gave Gemma 4 a very specific persona here:

'You are a live planetarium narrator with deep astronomy expertise. 
 Be vivid, poetic, scientifically precise, and cinematic.'

The prompt also feeds in the current compass direction, tilt angle, and which constellations are visible. Gemma uses all of that context to write something specific to what you're actually looking at.

This is where the 128K context window of Gemma 4 shines — I can pass rich contextual data and get nuanced, location-aware responses.

Feature 4: Planet Comparison — Gemma as Data Analyst

Pick any two planets, hit ANALYZE, and Gemma 4 breaks down the comparison like a scientist explaining it to a curious friend.

Mercury vs Mars:

SIZE CONTRAST: Mars is 1.4× wider than Mercury. DISTANCE: Mercury orbits at 57.9M KM from the Sun, while Mars orbits at 227.9M KM — a vast difference in solar energy received. TEMPERATURE: Mercury surface reads -180→430°C vs Mars's -125→20°C — Mercury and Mars represent extreme thermal environments.

The structured breakdown format comes entirely from the prompt. I didn't template the output — Gemma 4 just... organizes it that way when you ask it to.

Feature 5: The Space Q&A Chat

At the bottom of the Solar System view, there's a chat bar. Ask anything about space.

The system prompt is simple but effective:

'You are an expert space scientist. Answer questions about planets, moons, 
 satellites, black holes, and galaxies enthusiastically. Keep answers 2-4 
 sentences with specific numbers and surprising facts.'

The "specific numbers" instruction is key — it stops Gemma from giving vague answers and forces it to ground responses in real data.

Why Gemma 4? The Model Selection Decision

This was a deliberate choice, not a default.

I needed a model that could:

Switch personas instantly — NASA commander, planetarium narrator, planetary scientist, data analyst. All in the same app.
Produce short, precise outputs — The UI doesn't have space for essays. 2-3 sentences max.
Work reliably via API — The whole app runs client-side, so I needed a stable, fast endpoint.
Handle creative + factual tasks — Mission briefings need drama. Discovery Mode needs accuracy. Both at once is hard.

I went with gemma-4-27b-it (the 27B dense model via Google AI Studio's Gemini API).

Why 27B and not 2B or 4B?

The smaller models are amazing for edge/mobile deployment — but they struggled with the tonal range this app demands. A 4B model would give me a decent mission briefing or a poetic sky narration, but not both reliably. The 27B model handles persona-switching cleanly.

Why not the 26B MoE?

The MoE is built for high-throughput reasoning. My use case is lots of short creative + factual bursts, not long-chain reasoning. The dense 27B was the better fit here.

The killer feature: instruction following

Every Gemma 4 call in this app has a very specific system prompt. The model follows them precisely — it doesn't ramble, doesn't break character, doesn't exceed the sentence limit I set. That level of instruction-following made the entire UI feel polished.

Architecture (The Short Version)

The entire app is one HTML file. No frameworks, no build step, no server.

Cosmos Explorer
├── Canvas-based solar system (vanilla JS + requestAnimationFrame)
├── Real orbital mechanics (Kepler's equations)
├── ISS tracker (simulated TLE physics)
├── NASA images via JPL/APOD APIs
├── Space news via curated data
└── Gemma 4 via Gemini API (gemma-4-27b-it)
    ├── Mission briefings (on planet click)
    ├── Discovery Mode (on button press)
    ├── Sky CAM narration (on analyze)
    ├── Planet comparison (on analyze)
    └── Space Q&A (persistent chat)

The Gemma integration is surprisingly clean — one callGemma() function that every AI feature uses:

async function callGemma(systemText, userText, maxTokens = 350) {
  const url = `https://generativelanguage.googleapis.com/v1beta/models/gemma-4-27b-it:generateContent?key=${API_KEY}`;
  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      system_instruction: { parts: [{ text: systemText }] },
      contents: [{ role: 'user', parts: [{ text: userText }] }],
      generationConfig: { temperature: 0.85, maxOutputTokens: maxTokens }
    })
  });
  const data = await res.json();
  return data.candidates[0].content.parts[0].text.trim();
}

That's it. Every Gemma feature in the entire app flows through that one function. Clean, simple, powerful.

The Moment That Made Me Go "Whoa"

During testing, I clicked on Earth and asked Gemma to generate a mission briefing.

It said:

"TARGET ACQUIRED: EARTH. The only confirmed biosphere in the known universe. Magnetic field generated by liquid iron outer core deflects solar wind at 400 km/s. 71% surface liquid water. 8.1 billion crew members aboard. Protect at all costs."

"8.1 billion crew members aboard. Protect at all costs."

I didn't prompt that. The model extrapolated from the NASA commander persona and added something genuinely moving. That's the difference between a language model and a creative language model.

That line stayed in the app.

What's Next

Exoplanet Explorer — Gemma 4 generating habitability reports for Kepler catalog planets
Mission Planner — Ask Gemma to plan a hypothetical mission to any planet
Night Sky Events — Gemma narrating upcoming eclipses, conjunctions, meteor showers
Offline mode — Gemma 4 2B/4B running locally via WebGPU (no API key needed)

The offline idea excites me most. The 4B model is small enough to run in the browser — imagine a space education tool that works with zero internet, perfect for schools and rural areas.

Try It Yourself

🚀 Live Demo: cosmos-explorer-ishant.netlify.app

Open it, click Saturn, hit Discovery Mode, then go to Sky CAM and press Gemma AI Analysis. That sequence will show you everything Gemma 4 can do in about 60 seconds.

Final Thought

People talk about AI like it's a search engine replacement. But Gemma 4 did something different here — it became a narrator. It gave this app a voice, a personality, a sense of drama.

Space is the most dramatic story humanity has ever told. I just needed an AI good enough to tell it.

Gemma 4 was that AI. 🌌

Built with vanilla JS, Canvas API, and Gemma 4 via Google AI Studio.

No frameworks were harmed in the making of this app.

Thanks for reading!!

Tags: #gemma4 #googleai #javascript #space #webdev #ai #opensource

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: