Amazon Quick multi-dataset Topics: unified semantic layer

Amazon Quick is introducing multi-dataset Topics in public preview, allowing a single Topic to include up to 12 datasets and explicitly defined relationships so the Quick chat agent can traverse joins and return unified answers. The feature keeps datasets normalized, centralizes governance, and surfaces cross-dataset calculations and visuals without forcing authors to denormalize data.

How do multi-dataset Topics work?

Multi-dataset Topics let a Topic span multiple enriched datasets (up to 12 in preview), hold relationships between dataset pairs, and store custom instructions and permissions. Each dataset keeps its own enrichment metadata (column descriptions, synonyms, semantic types, calculated fields, exclusions), relationships are provided via an uploaded JSON file that maps join keys, and topics expose those combined semantics to the NLQ engine and authors.

Enrichment is applied per dataset so the NLQ engine maps user language to the right columns using column names, descriptions, and synonyms. Topics include permissions where owners can modify the topic and viewers can ask questions or use the topic in analysis without changing configuration. The same multi-dataset topic supports building analysis visuals and answering questions through the chat agent.

How does the Quick chat agent generate cross-dataset answers?

The chat agent follows a four-step pipeline: intent parsing, relationship traversal, SQL generation, and result presentation. It first maps user terms to columns using the enrichment metadata and determines the datasets involved. Next it uses defined join keys to find the shortest join path between datasets. Then it constructs SQL with appropriate JOIN clauses and aggregations. Finally it returns a visualization or table and exposes the generated SQL for inspection.

The documentation provides a concrete example for the question “Show total sales by customer segment and store region.” The engine maps terms to columns and determines three datasets are required: SALES_FACT, CUSTOMER_DIM, and STORE_DIM, with join keys SALES_FACT.CUSTOMER_ID -> CUSTOMER_DIM.CUSTOMER_ID and SALES_FACT.STORE_ID -> STORE_DIM.STORE_ID. The engine produces SQL such as:

SELECT c.SEGMENT AS customer_segment, s.REGION AS store_region, SUM(f.SALE_AMOUNT) AS total_sales FROM SALES_FACT f JOIN CUSTOMER_DIM c ON f.CUSTOMER_ID = c.CUSTOMER_ID JOIN STORE_DIM s ON f.STORE_ID = s.STORE_ID GROUP BY c.SEGMENT, s.REGION ORDER BY total_sales DESC

Users can inspect that generated SQL using the Explanation feature so the join path and chosen columns are transparent. The richer the enrichment metadata and custom instructions, the more accurately the NLQ engine interprets ambiguous queries.

What are the current limits and supported sources?

During private preview, multi-dataset Topics support SPICE datasets. Public preview expands Direct Query support to Amazon Redshift, Amazon Athena, Amazon S3 Tables, Snowflake, and Databricks. The service does not allow combining SPICE and Direct Query datasets within a single topic as of today. For visual building, Quick Sight represents datasets as flattened tables historically, but multi-dataset Topics remove the requirement to denormalize by enabling explicit relationships and cross-dataset calculated fields.

The walkthrough in the documentation models a retail scenario with a star schema using SALES_FACT as the central fact table and dimension tables CUSTOMER_DIM, PRODUCT_DIM, STORE_DIM, and DATE_DIM. Authors can create calculated fields that reference columns across datasets while the engine manages the underlying join logic.

Why it matters

Multi-dataset Topics change the practical trade-offs teams face when modeling Quick Sight semantic layers. Organizations no longer need to build one big denormalized table to avoid run-time joins. Keeping data normalized preserves governance and reduces duplication. Authors gain the ability to build visuals and calculations that combine measures and dimensions from separate datasets while the NLQ engine handles join path resolution and SQL generation for business users.

This shifts a common Quick Sight constraint — one visual sourced from a single flattened dataset — toward a more flexible model where the semantic layer, not end users, expresses relationships.

What to watch

Track when public preview rolls out broadly and whether support for mixing SPICE and Direct Query within a single topic is added. Also watch for feature availability updates for Quick Sight BI visual building and any expansion of supported Direct Query sources or limits beyond the current preview cap of 12 datasets.