[Update] I tried natural language queries on four datasets using Amazon QuickSight multi-dataset topics

This is Ishikawa from the Cloud Business Division. Since Amazon QuickSight topics now support runtime joins across multiple datasets, I tried out natural language queries on multi-dataset topics in the Management Console.

https://aws.amazon.com/jp/about-aws/whats-new/2026/08/amazon-quick/

Previously, to perform analysis spanning multiple tables in Amazon QuickSight, you needed to manually build JOIN logic during the data preparation stage and pre-join everything into a single dataset. With this update, you can keep each dataset at its original granularity and define relationships (join keys) on the topic side, so that only the necessary joins are assembled at query execution time.

You can add up to 12 datasets to a single topic, and the same semantic model is used both when creating visuals on analysis sheets and when doing natural language Q&A in Amazon Quick Chat. Row-level security (RLS) and column-level security (CLS) are inherited directly from the existing dataset permissions.

https://aws.amazon.com/blogs/machine-learning/build-a-unified-semantic-layer-across-datasets-with-multi-dataset-topics-in-amazon-quick/

Note that Amazon QuickSight has evolved into Amazon Quick, and the BI functionality is now called Amazon QuickSight.

What Are Multi-Dataset Topics

A topic is a multi-dataset semantic layer that consolidates multiple enriched datasets into a single unified data model.

The differences from the previous approach are as follows.

In the official documentation, a topic is described as consisting of four layers.

The "Relationships" element shown with a dashed border cannot be configured via the API including CloudFormation — it is console-only. We will verify this point later.

Relationships are defined by uploading a JSON file that describes the dataset pairs and the column names used for joining. The official documentation Defining relationships between datasets in a Topic includes an example of a star schema that joins a central sales fact table to each dimension table.

{
  "datasetPairs": [
    {
      "datasetLeft": { "datasetName": "SALES_FACT", "joinColumnNames": ["CUSTOMER_ID"] },
      "datasetRight": { "datasetName": "CUSTOMER_DIM", "joinColumnNames": ["CUSTOMER_ID"] }
    },
    {
      "datasetLeft": { "datasetName": "SALES_FACT", "joinColumnNames": ["PRODUCT_ID"] },
      "datasetRight": { "datasetName": "PRODUCT_DIM", "joinColumnNames": ["PRODUCT_ID"] }
    },
    {
      "datasetLeft": { "datasetName": "SALES_FACT", "joinColumnNames": ["STORE_ID"] },
      "datasetRight": { "datasetName": "STORE_DIM", "joinColumnNames": ["STORE_ID"] }
    }
  ]
}

The limitations listed in the official documentation are as follows.

• The relationship graph must be acyclic (DAG); circular joins are not supported
• Self-relationships (associating a dataset with itself) are not supported
• SPICE and Direct Query cannot be mixed within a single topic

https://docs.aws.amazon.com/quick/latest/userguide/topics-relationships.html

Key Changes

• You can now add up to 12 datasets to a single topic and define join keys (relationships) between dataset pairs
• When you create a visual using fields from multiple datasets on an analysis sheet, Amazon QuickSight automatically generates a runtime inner join
• In Amazon Quick Chat, an LLM-based chat agent follows the relationships and generates SQL that spans datasets to answer your questions. The generated SQL can be reviewed
• Custom instructions allow you to permanently define business rules in natural language, such as fiscal year definitions, metric calculation logic, and disambiguation of terminology
• Existing dataset permissions are inherited, with support for row-level security (RLS) and column-level security (CLS). RLS is applied per dataset during runtime joins
• Topics created before this release are classified as legacy Topics and continue to work as before

By eliminating the need for pre-joins, you no longer have to rebuild datasets every time a use case changes, and you can avoid excessive SPICE capacity consumption. Another major benefit is that both humans and agents reference the same semantic model, enabling consistent application of data governance across cross-dataset visuals.

Supported Regions

Generally available (GA) in all AWS Regions where Amazon Quick is available, including the Tokyo Region (ap-northeast-1). Note that Amazon QuickSight topics require the Enterprise Edition.

Trying It Out

Prerequisites

• Amazon QuickSight Enterprise Edition account
• QuickSight user role: ADMIN_PRO
• Verification region: ap-northeast-1 (Tokyo)

The edition was confirmed with the following command.

% aws quicksight describe-account-subscription \
  --aws-account-id "${ACCOUNT_ID}" \
  --query 'AccountInfo' --output json
{
    "AccountName": "q-in-quicksight-sandbox",
    "Edition": "ENTERPRISE",
    "NotificationEmail": "ishikawa.satoru@classmethod.jp",
    "AuthenticationType": "IDENTITY_POOL",
    "AccountSubscriptionStatus": "ACCOUNT_CREATED"
}

Note that resource names in the following sections have been shortened to the mds- prefix for readability. In the actual verification, names with execution IDs were used.

Preparing SPICE Datasets with a Star Schema

Following the JSON example in the official documentation, I created a star schema in CSV format with SALES_FACT at the center and CUSTOMER_DIM / PRODUCT_DIM / STORE_DIM arranged around it, placed the files in S3, and turned them into SPICE datasets.

SALES_FACT

CUSTOMER_DIM

STORE_DIM

PRODUCT_DIM

Creating a Multi-Dataset Topic

Select 4 DataSets and create a topic (mds-star).

On the next screen, configure the relationships between the selected datasets in the [Relationships] tab.

Next, in the [Custom Instructions] tab, register business rules in natural language.

- "Fiscal year starts April 1. Interpret 'this year' using fiscal year boundaries."
- "Active customers means customers with at least one purchase in the last 90 days."
- "When 'sales' is mentioned without qualification, default to net_sales_amount."
- "Return rate = count of returned items (RETURN_FACT) / total items sold (SALES_FACT), as a percentage."

Finally, publish (share) the configured topic.

Selecting the Topic to Query

Select "New Chat" from the left navigation menu, then select the topic to query.

Select the multi-dataset topic you created (mds-star).

Querying the Multi-Dataset Topic in Natural Language

I ask a question using analysis dimensions: "Please tell me the product names and total sales that Customer-001 purchased at Store-01." Without joining the fact table (SALES_FACT dataset) with each dimension (CUSTOMER_DIM dataset, STORE_DIM dataset, PRODUCT_DIM dataset), this question cannot be answered correctly.

The purchased product name "Product-030", the records, and the total sales were all retrieved correctly.

Addendum: Can SPICE and Direct Query Really Not Be Mixed?

I also tested the restriction that "SPICE and Direct Query cannot be mixed within a single topic." When I tried adding the SPICE SALES_FACT created this time together with an existing Direct Query dataset superstore_joined_jp, it failed with an error as expected.

All datasets in a SEMANTIC_VIEW topic must use the same query mode.
Dataset superstore_joined_jp uses DirectQuery mode, but dataset STORE_DIM uses SPICE mode.
(errorCode: MIXED_DATASET_QUERY_MODE)

Discussion

Here is a summary of the insights gained from this verification.

Cross-Dataset Questions Were Answered Without Pre-Joins

The question "What product names and total sales did Customer-001 purchase at Store-01?" cannot be answered without spanning one fact table and three dimension tables. Previously, you would have needed to prepare a single dataset with all four tables already JOINed, but simply defining relationships in the topic was enough to return the correct values for the product name, records, and total sales.

Since each dataset can be kept at its original granularity, there is no longer a need to rebuild JOIN-ed datasets every time a new use case arises. The total SPICE consumption for the four datasets in this test was about 51 KB, which is more efficient compared to maintaining a separately pre-joined dataset.

The Console Blocks Mixed Query Modes

When attempting to put the SPICE STORE_DIM and the Direct Query superstore_joined_jp in the same topic, the request was rejected with the dedicated error code MIXED_DATASET_QUERY_MODE. This confirms that the constraint documented is properly enforced in the UI.

The term SEMANTIC_VIEW appearing in the error message also reveals that the new topic type is handled internally as a semantic view.

Relationship Definitions Are Console-Only

This is the part shown with a dashed border in the diagram at the beginning. The keys returned by describe-topic under Topic are only four: Name, Description, UserExperienceVersion, and DataSets — there is no field corresponding to Relationships.

Star Schema Is the Standard Starting Point for Design

The official documentation recommends modeling with a star schema, where one or more central fact tables are joined to shared dimension tables. Use integer surrogate keys for join keys wherever possible, and make sure to verify that data types match on both sides, that NULLs are removed (NULLs do not match in inner joins), and that referential integrity is maintained.

For snowflake structures where dimensions have sub-dimensions hanging off them, it is recommended to flatten them into a single dimension dataset in order to reduce join hops. Since the relationship graph must be acyclic (DAG), if a cycle would be created, drop one of the paths and denormalize.

Features I look forward to in the future include:

• Adding Relationships to TopicDetails (IaC support via CloudFormation / API)
• Validation of dataset count limits and mixed query modes in CreateTopic / UpdateTopic
• Support for outer joins on analysis sheets

Closing Thoughts

Amazon QuickSight topics have evolved into a multi-dataset semantic layer capable of defining relationships across up to 12 datasets and performing runtime joins. Since you no longer need to create pre-joined flat datasets, you can reduce data preparation effort and SPICE capacity while analyzing data in a normalized data model.

When I actually tried it out, simply selecting four datasets from the console and configuring the relationships was enough to correctly answer natural language questions that span multiple datasets. The fact that both analysis sheets and natural language chat share the same semantic model is also a significant advantage from a governance perspective.

If you have an environment where JOIN-ed datasets keep proliferating every time a new use case arises, why not consider migrating with star schema modeling in mind?