Build an AI travel planner easily with Google Cloud's Multi Model Spanner

Database sprawl is the silent killer of fast AI development. If you’ve ever built an AI product with user intent, recommendations, or intelligent routing, you’ve fought this pain: juggling a transactional store, a vector engine for semantic search, and a third database for relationship graphs. Every added system means ETLs, sync jobs, and a mess of APIs. What changes if all of that disappears? Google Cloud Spanner just shipped as a real multi model database — meaning it can serve relational, vector, graph, and analytic workloads directly, under global consistency. Building Google Cloud Spanner multi model database apps is shifting from slog to flow.

Let’s see how this powers a real-world AI Travel Planner for San Francisco, delivered start to finish with Vibe Coding that finally lets data and AI talk — without glue code. This isn’t blue-sky, it’s running now. Here’s what it enables, and how you can build with it today.

What is Google Cloud Spanner Multi Model Database and why does it matter?

Spanner’s claim isn’t incremental. For over a decade, Spanner has backed Gmail, YouTube, and Google Photos — handling over 6 billion queries per second at peak, spanning 17 exabytes, with five 9s (99.999%) availability and globally distributed consistency. That scale isn’t up for debate.

What’s new: Spanner now runs multiple data models in the exact same distributed instance. Relational tables, graph relationships, vector embeddings, full-text and analytical search — all stored and queried together. No separate vector DB, no sidecar graph store.

The legacy pain: data model sprawl

Typical AI architectures mean juggling multiple specialist databases:

• Relational (Postgres, Spanner, MySQL) for transactions, bookings, users
• Vector (Pinecone, Vertex AI, Weaviate) for semantic search or recommendation
• Graph (Neo4j, TigerGraph) for connections and relationships

Each handles one slice. Together, they explode schema mapping, pipelines, and operational risk. Every ETL or sync job is another moving part that breaks. Analytics slow down; debugging crosses APIs.

Spanner’s new model: all of those data needs in one system. Fewer silos. Fewer syncs. Much less complexity.

Takeaway: Instead of bolting together a zoo of fragile, specialized stores, you can build an AI product on a single service — at the scale Google trusts for itself.

How does Google Cloud Spanner power an AI Travel Planner?

Spanner’s multi model backbone changes how you can architect AI agents. The demo built a travel planner for San Francisco: one agentic system that books trips, answers questions, and understands intent, all without jumping between databases.

Three workloads, one base

1. Transactional: Relational data tracks bookings, trip itineraries, places. No glue needed — this is the backbone.
2. Semantic: Vector search means the planner matches user requests (“hotel with rooftop view near Golden Gate Park” or “Itinerary for art lovers on Wednesday”) to real points of interest, instantly. No ETL from your Postgres to Pinecone: embeddings live in the same DB.
3. Graph: Relationships (e.g., “people who travel together,” “attractions grouped by neighborhood,” “visited by X users”) are plain tables or integrated graph functions. All via direct SQL.

The kicker: one database does it all, with immediate consistency and uniform security, and no hand-written sync code.

Real-time AI, not laggy pipelines

Building the San Francisco AI Travel Planner, every agent step — understanding user intent, updating an itinerary, recommending the next stop — hits Spanner via unified queries. That means no joining across datastores, no latency from downstream jobs, and a simplified mental model for the developer.

You ship a single, atomic product. The system learns faster, responds with less lag, and never gets out of sync.

Takeaway: AI agents with intent and recommendations run in real time on a unified data surface, not on weekly pipeline drops.

What is Vibe Coding and how does it accelerate development?

Vibe Coding is the gap between “build it” and “it’s built.” It means writing code fast, in a flow, using natural language and modern agentic tools. The demo shipped with tools like Anti-Gravity — a suite designed for AI-native, rapid, multimodal development.

Vibe Coding in practice

• Natural language first: Describe schemas, queries, and logic in your words. Modern tools parse and generate code or console steps.
• AI-native building blocks: Tooling that expects you to work with vectors, graphs, and agents, not retrofitted SQL GUIs.
• Iterate at chat speed: Build, swap, and test features as fast as you can describe them. No formal update/redeploy loop for minor tweaks.

For GenAI newcomers, this means you get power fast — no five-stack learning curve, just spin up an agent without days of setup. For veterans, it’s about removing boilerplate and glue: you never have to stop to “shoehorn” a search engine or maintain brittle ETLs.

The result: shipping complex, agentic AI systems on a unified data stack at a speed that would have looked reckless in 2019.

Takeaway: Vibe Coding plus Spanner’s multi model DB means you build modern AI software at the speed of thought, not ticketing.

How to use Google Cloud Spanner as a multi model database today

You can build multi model workloads on Spanner now. Here’s how a developer would actually try this — no napkin architecture, just the real steps.

1. Set up a Spanner instance

You start with a standard GCP project.

# Authenticate with GCP CLI
gcloud auth login

# Create a Spanner instance
gcloud spanner instances create my-multimodel-db \
    --config=regional-us-central1 \
    --description="Multi-model AI backend" \
    --nodes=1

2. Enable multi model features

Multi model comes with new Spanner engine options. Enable the features via the console or CLI:

# Enable vector and graph extensions (example; check GCP docs for current syntax)
gcloud spanner databases ddl update my-database \
    --instance=my-multimodel-db \
    --ddl-file=schema/enable_multimodel.ddl

Your DDL brings together relational, vector, and graph schemas:

CREATE TABLE Users (
  UserID STRING(36) NOT NULL,
  Name STRING(MAX),
  Embedding BYTES(768)  -- vector embedding for semantic search
) PRIMARY KEY(UserID);

CREATE TABLE Attractions (
  AttractionID STRING(36) NOT NULL,
  Name STRING(MAX),
  Location STRING(MAX),
  Embedding BYTES(768)
) PRIMARY KEY(AttractionID);

-- Graph: relationships between users and attractions
CREATE TABLE Bookings (
  BookingID STRING(36) NOT NULL,
  UserID STRING(36) NOT NULL,
  AttractionID STRING(36) NOT NULL,
  Date DATE,
) PRIMARY KEY(BookingID);

Now you can query across models: find users with similar tastes (vector), or build a trip graph in plain SQL.

3. Ingest data: relational + graph + vector

For vectors: you store embeddings directly alongside user and attraction records (usually as BYTES, mapped from your model). For graph: any “links” table can be traversed in queries.

4. Query multi model

Sample query: “Which users are most similar to this one, who have also booked attractions in the Mission?”

SELECT u2.UserID, u2.Name
FROM Users u1
JOIN Users u2 ON VECTOR_COSINE(u1.Embedding, u2.Embedding) > 0.85
JOIN Bookings b ON b.UserID = u2.UserID
JOIN Attractions a ON a.AttractionID = b.AttractionID
WHERE u1.UserID = @SourceUserID
  AND a.Location = 'Mission District'

5. Optimize for mixed workloads

• Schema: Keep embeddings compact. Avoid duplicating relationships: one graph table, cross-join as needed.
• Indexing: Use Spanner’s secondary indexes for hotspot queries (e.g., attractions by region, users by intent).
• Query tuning: Vector operations can be compute-heavy — filter with relational logic first, then apply vector search.

Result: you handle hundreds of thousands of hybrid queries per second, globally, with consistency.

Takeaway: Spanner’s unified approach lets you build a single system that replaces three — with cloud-native scale and no glue.

What are the benefits and challenges of using Spanner for agentic AI?

Agentic AI is about systems that act on goals, not just respond. An agentic travel planner parses free-form user requests, recommends, plans, and books — autonomously — often in real time.

Key benefits

• Unified data view: No more reconciling data across silos. Agents see the world through one schema.
• Scalability and consistency: Spanner’s global scale isn’t marketing — it withstands planetary traffic and stays consistent.
• Performance: With the right schema, vector and graph queries run within transactional scope — low-latency recommendations, no batch jobs.

Challenges

• Learning curve: Spanner’s model is not trivial. You must think globally and query across mixed data types.
• Cost: Global DBs aren’t the cheapest baseline. Projects must scope for both storage and compute, especially for vector-heavy workloads.
• Tooling: The ecosystem is evolving — expect migration from specialized tools to first-party Spanner CLIs, GUIs, and AI assistants.

Takeaway: If your agentic AI is bottlenecked by sprawl or pipeline lag, unified multi model Spanner is a real lever — if you’re ready for the ramp.

Future of database architecture: how Google Cloud Spanner fits into it

The industry is converging on one lesson: database consolidation wins in the long run. The stack is moving past “one model per system.” Multi model databases are the next logical step, and Spanner comes from a place of proven reliability at scale.

Spanner’s decade-plus of uptime and exabyte data handling is the foundation. The new multi model functions — especially vector and graph support — mean you can now run AI features side-by-side with global transactions and analytics, with consistency.

Google Cloud’s tie-in: these kind of unified databases now coordinate directly with first-party AI services, native eventing, and global serving.

Takeaway: What started as the world’s most reliable relational warehouse is now a one-stop data layer for modern, agentic AI.

Closing: one database, one flow

Google Cloud Spanner multi model database is the most credible answer yet to database sprawl. By merging relational, vector, graph, and analytic workloads into one system, Spanner lets developers and AI apps work on a single, consistent source of truth. No more juggling ETLs or wrangling Spark jobs for every new AI feature. With the rise of Vibe Coding and tools built to work with these new primitives, the path from idea to shipped AI system is shrinking fast. The future of agentic, intelligent apps is one system deep — and Spanner has already crossed that line.

For a full walkthrough, see Vibe Coding with Google Cloud's Multi Model Spanner: Building an AI Travel Planner.