This post was originally published on this site

In today’s retail environment, shoppers expect highly personalized product discovery experiences and conversational assistance that feels genuine, natural, and genuinely helpful. Today, successful product discovery is about understanding semantic meaning and the rich, connected relationships between products, categories, and guest intent. It is no longer just about keywords and basic browsing. 

At Target, this work is handled by our Guest Product Confidence platform team. They are responsible for building the features that establish trust and guide purchasing decisions, such as ratings, reviews, and AI-driven digital shopping assistants. An exciting example of this is our Gift Finder chat agent, which we launched during the 2025 holiday season online and in the Target app to help shoppers discover the perfect items through friendly, conversational dialogue.

To deliver real-time personalization and context-rich semantic responses like these at global scale, we identified a critical architectural need to move away from a fragmented data ecosystem toward a unified data platform. We needed a solution capable of supporting high-throughput transactional workloads, highly connected graph relationships, vector similarity search, and full-text keyword search all at once. 

In this post, we’ll explore how we achieved all four with Spanner.

Overcoming fragmented architecture

Previously, Target’s discovery data ecosystem relied on a combination of Elasticsearch clusters for search and inverted indexes, alongside separate NoSQL datastores for our transactional data. While functional, this fragmented architecture presented significant operational and technical challenges.

  • Disconnected context: Keeping separate search, vector, and transactional databases in perfect sync was a constant challenge. Siloed information led to missing context, disconnected attribute relationships, and inconsistent query results.

  • High operational overhead: Managing independent clusters, tuning search indexes, and handling complex, custom synchronization and aggregation logic required intensive manual intervention from our engineering teams.

  • Expansion bottlenecks: Expanding our retail data domains required adding new database collections, maintaining complex joins, and navigating weak transactional guarantees across our discovery and core transactional systems.

  • Siloed intelligence: We lacked the ability to query graph relationships, vector similarity, and keyword search indexes in a single transaction.

To build the next generation of AI-driven guest experiences, we needed to consolidate on one platform.

Building the enterprise ontology on Spanner Graph

We evaluated multiple specialized technologies, including standalone vector databases and niche graph databases. However, adding more single-purpose databases would have only worsened our operational complexity and data synchronization pipelines.

We ultimately chose Spanner Graph to build our enterprise ontology, which is a “graph-of-graphs” paradigm that allows us to construct a massive, generative AI-powered shopping graph.

By unifying our data, we bring semantic data, graph relationships, vector embeddings, and operational transactions under one roof. This establishes Spanner as our single authoritative source of truth for both transactional state and semantic intelligence.

Our high-level architecture now consists of three core pillars:

1. Enterprise augmentation
This layer captures our enterprise retail catalog, aggregates relevant metadata from multiple backend sources, and utilizes generative AI for agentic data enrichment to dramatically improve the quality and depth of the product data we ingest.

2. Unified graph, vector, and search store 
Instead of shifting data across multiple databases, Spanner Graph stores our entity nodes, relationship edges, and vector embeddings in the same database engine. Spanner Graph natively supports multi-hop graph traversals, semantic vector similarity, and full-text keyword queries over our relational tables. Because this multi-model synergy is native, we get strict ACID transactions for absolute correctness across distributed workloads without the need for fragile external sync pipelines.

3. Orchestration and AI layer
This layer powers our conversational guest interfaces, utilizing rich, structured context fed directly from Spanner Graph to ground our LLMs. It extracts highly specific product relationships to power tools like the Gift Finder while governing responsible AI processes and evaluating generated outputs.

A smooth, zero-downtime incremental migration

Transitioning critical search and discovery infrastructure that millions of guests rely on required a cautious, zero-downtime approach. We executed this migration in four structured phases.

  1. Schema and ontology mapping: We defined the specific retail entities, such as products, categories, brands, and guest preferences, and their corresponding relationships within the Spanner Graph schema.

  2. Data integration and parallel replay: We built mutation-based data integrations in a parallel pipeline. This allowed us to continuously replay live transactional updates, apply schema transformations, generate embeddings, and write them directly into Spanner Graph in real-time.

  3. Canary deployment: We gradually shifted live read traffic to the new Spanner Graph-backed platform, validating query performance, semantic accuracy, and database stability under real retail workloads.

  4. Cutover and cleanup: Once performance was thoroughly verified, we fully transitioned all search and discovery traffic to Spanner and deprecated our legacy Elasticsearch stack, entirely removing the maintenance burden of those clusters.

Business impact

By building directly on Spanner Graph, we unlocked measurable technical and business outcomes:

The ultimate GraphRAG foundation: Traditional RAG relies on flat vector similarity, which often misses the structured associations between products, such as matching a toy with its compatible accessories or age-appropriateness. By combining deep graph traversals with semantic vector search in a unified GraphRAG architecture, we grounded our LLMs with highly precise context. This directly improved our recommendation relevancy, enhanced guest satisfaction, and boosted our Net Promoter Score.

Consolidated SQL + GQL interoperability: With Spanner Graph, our developers query structured relational catalog data and connected graph relationships in a single query using standard SQL and GQL (Graph Query Language). This eliminates the need for data duplication, latency, or complex ETL pipelines to bridge these paradigms.

Serverless scalability with zero growth ceiling: Spanner automatically handled massive, unpredictable traffic spikes during peak retail events like Black Friday and Cyber Monday. Spanner’s built-in autoscaler dynamically adjusted computing capacity to handle burst traffic during high-intensity, limited-time promotional offers without sacrificing performance.

50% reduction in infrastructure maintenance: By consolidating our transactional NoSQL and search index databases into a single managed Google Cloud service, we eliminated the operational burden of maintaining separate database clusters. Our developers now spend 50% less time on database administration and infrastructure upkeep, allowing us to build and deploy new, customer-facing AI features much faster.

Migrating to Spanner Graph has accelerated our generative AI roadmap, serving as the ultimate proof of what is possible when you build on the right data foundation

Want to supercharge your AI apps? It starts with databases with the right graph capabilities at virtually unlimited scale. Discover how Spanner Graph can turn data into action for your organization.