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 have ever built an AI product with user intent, recommendations, or intelligent routing, you have fought this pain: juggling a transactional store, a vector engine for semantic search, and a third system for relationship data. Every added system means ETL jobs, sync lag, and a mess of APIs. Google Cloud Spanner's multi-model direction says all of that can collapse into one place — relational, vector, and analytic workloads served from the same distributed instance, so building data-backed AI apps shifts from slog to flow.

Here is what that enables, shown through a real-world AI travel planner for San Francisco, and how you can build with it today.

What Spanner's multi-model support actually is

Spanner is Google Cloud's globally distributed relational database — the system Google built for planet-scale transactional workloads with external consistency (Google Cloud Spanner). What is new is that the same instance now serves more than rows and tables: vector embeddings can be stored, indexed, and queried directly alongside relational data.

The load-bearing fact comes straight from Google's docs: Spanner's vector search is "a high-performance, built-in capability" where "storing and indexing vector embeddings directly within your transactional database" means Spanner "eliminates the need for separate vector databases and complex ETL pipelines" (vector search overview). It supports exact K-nearest-neighbor search plus approximate nearest neighbor search on a ScaNN-based vector index, with inline filtering that combines vector similarity and structured metadata predicates in one query.

That is the whole thesis in one paragraph: one system, one consistency model, one security surface — instead of a zoo of specialist stores.

The legacy pain: data model sprawl

Typical AI architectures juggle multiple specialist databases:

• Relational (Postgres, MySQL, Spanner) for transactions, bookings, users
• Vector (Pinecone, Weaviate, Vertex AI Vector Search) for semantic search and recommendations
• Relationship stores for connections between people, places, and events

Each handles one slice. Together, they explode schema mapping, pipelines, and operational risk. Every ETL or sync job is another moving part that breaks at 2 AM. Analytics slow down, debugging crosses API boundaries, and the vector index is always slightly stale relative to the source of truth.

Spanner's answer: keep those workloads in one system. Fewer silos, fewer syncs, much less complexity. If you are already running Postgres with row-level security in production, the same consolidation instinct applies — see our production RLS checklist for what a single-database security posture looks like in practice.

Takeaway: instead of bolting together fragile specialist stores, you can build an AI product on a single service with global consistency.

How one database powers an AI travel planner

Spanner's multi-model backbone changes how you architect AI agents. Consider a travel planner for San Francisco: one agentic system that books trips, answers questions, and understands intent, without jumping between databases.

Three workloads, one instance

1. Transactional: relational tables track bookings, itineraries, and places. This is the backbone — plain SQL, ACID transactions, no glue.
2. Semantic: vector search matches user requests ("hotel with a rooftop view near Golden Gate Park", "itinerary for art lovers on Wednesday") to real points of interest instantly. Because embeddings live in the same database, there is no ETL from Postgres to a sidecar vector store — and inline filtering means "similar to this, but under $200 a night" is one query, not two systems (vector search overview).
3. Relational connections: relationships like "people who travel together" or "attractions grouped by neighborhood" are join tables traversed in SQL. No separate graph cluster to operate — the connections are just more relational data queried with the same engine.

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

Real-time AI instead of laggy pipelines

Every agent step — understanding user intent, updating an itinerary, recommending the next stop — hits Spanner through unified queries. No joining across datastores, no latency from downstream jobs, no "the recommendations update nightly" caveats. The system responds with less lag and never drifts out of sync with itself.

That real-time property is what makes background job design simpler too: when the database is the single source of truth, your background job architecture stops being a distributed reconciliation problem and starts being a queue over one consistent store.

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

Build on Spanner's multi-model features today

You can build vector-plus-relational workloads on Spanner now. Here is the practical path — with one honesty flag up front: DDL syntax and client libraries evolve, so treat the snippets below as illustrative scaffolding and confirm the current form against Google's vector search docs before shipping.

1. Set up a Spanner instance

Start with a standard Google Cloud project and create an instance sized for your workload:

# Authenticate with the Google Cloud 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. Model relational data and embeddings together

The conceptual schema keeps embeddings next to the rows they describe. Illustrative shape:

-- Illustrative: confirm current vector column types in the docs
CREATE TABLE Users (
  UserID   STRING(36) NOT NULL,
  Name     STRING(MAX),
  Embedding ARRAY<FLOAT32>  -- semantic profile of the traveler
) PRIMARY KEY (UserID);

CREATE TABLE Attractions (
  AttractionID STRING(36) NOT NULL,
  Name         STRING(MAX),
  Location     STRING(MAX),
  Embedding    ARRAY<FLOAT32>  -- semantic profile of the place
) PRIMARY KEY (AttractionID);

-- Relationships are plain tables traversed in SQL
CREATE TABLE Bookings (
  BookingID    STRING(36) NOT NULL,
  UserID       STRING(36) NOT NULL,
  AttractionID STRING(36) NOT NULL,
  TripDate     DATE,
) PRIMARY KEY (BookingID);

3. Ingest once, query everywhere

Vectors are generated by your embedding model of choice and written alongside the row — one write path, no CDC pipeline into a second system. Google's docs note you can generate embeddings from first-party models directly inside the query flow, and that LangChain integrates with Spanner vector search (vector search overview).

4. Query across models

The signature query — "travelers similar to this one who booked attractions in the Mission" — combines a similarity predicate with relational joins and a metadata filter in a single statement. Spanner's inline filtering exists precisely so this pattern stays fast: structured predicates prune the space before or alongside the vector scan.

5. Optimize for mixed workloads

• Filter first: apply relational predicates (neighborhood, price, date) before or with the vector scan to bound compute.
• Index deliberately: secondary indexes on hotspot access paths (attractions by region, users by intent segment).
• Keep embeddings compact: dimensionality is a cost lever on every query — benchmark recall at smaller sizes before defaulting to large vectors.

Takeaway: one system replaces the relational-plus-vector two-step, with cloud-native scale and no glue.

Benefits and trade-offs for agentic AI

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

Key benefits

• Unified data view: agents see the world through one schema. No reconciling three stores' versions of the same user.
• Consistency at scale: Spanner's global distribution and external consistency hold for vector-plus-relational queries alike.
• One security surface: access control, audit, and encryption live in one place. Our AI app security checklist covers what to verify before agents touch production data.

Honest challenges

• Learning curve: thinking in mixed workloads — transactional plus vector — is a genuinely new query-planning skill.
• Cost: globally distributed databases are not the cheapest baseline. Scope storage and compute for vector-heavy access patterns before committing.
• Evolving tooling: client libraries, ORMs, and agent frameworks are still catching up to multi-model query patterns.

Takeaway: if your agentic AI is bottlenecked by sprawl or pipeline lag, a unified database is a real lever — if you are ready for the ramp.

Where database architecture is heading

The industry is converging on one lesson: consolidation wins in the long run. The stack is moving past "one model per system" toward databases that serve transactions, search, and AI features from a single engine with a single consistency story. Spanner's vector search — in-database embeddings, ScaNN-based ANN plus exact KNN, inline filtering, LangChain support — is that convergence arriving in a system with a decade-plus operational record.

The practical consequence for builders: the database stops being the reason your AI feature ships late. When embeddings, metadata, and transactions live together, the distance from "the model understood the user" to "the product acted on it" is one query.

One database, one flow

Spanner's multi-model direction is the most credible answer yet to database sprawl: relational, vector, and analytic workloads in one consistent system, so developers and AI apps work from a single source of truth. No more ETL babysitting for every new AI feature. Pair that unified backend with a codebase your agent can actually read and ship — browse the production-ready starters at OTF templates — and the path from idea to shipped AI system keeps shrinking.

Sources

• Spanner vector search overview — in-database embeddings, ScaNN-based ANN plus KNN, inline filtering, LangChain integration
• Google Cloud Spanner — globally distributed relational database
• Production RLS checklist — single-database security posture
• AI production background jobs — queue design over one consistent store
• AI app security checklist — pre-production verification for agent data access

Originally published at otf-kit.dev — full-stack kits your AI coding agent can actually ship to production. See the kits →