Amazon Q in QuickSight is the generative-AI layer inside Amazon QuickSight, AWS's managed business-intelligence service. It lets anyone build dashboards and visuals from a plain-English prompt, get one-click executive summaries of what changed, ask data questions in natural language, and auto-generate data stories and narratives. This guide covers the four capabilities, the setup and data-prep that make answers trustworthy, the author-and-reader pricing model, concrete use cases, and how generative BI differs from traditional dashboard BI.
Amazon Q in QuickSight is the generative-AI capability set built into Amazon QuickSight, AWS's fully-managed, serverless business-intelligence service. It is one of the surfaces of the broader Amazon Q family — "Q in QuickSight" — rather than a standalone product you license on its own.
Amazon QuickSight has been AWS's cloud BI tool for years: you connect data sources, build datasets, author interactive dashboards, and publish them to readers across the organization, all without managing servers. Amazon Q in QuickSight is the generative-AI layer that sits on top of that BI engine. It turns natural language into analytics work — authoring visuals from a prompt, narrating dashboards in plain English, answering data questions conversationally, and assembling data stories — so that building and consuming BI no longer requires you to be fluent in the tool's drag-and-drop interface or in SQL.
It is important to place Q in QuickSight correctly within the Amazon Q family. Amazon Q is AWS's umbrella brand for generative-AI assistants. Two of them are licensed products you buy per seat: Q Developer and Q Business. The rest are embedded capabilities inside other AWS services — and Q in QuickSight is the BI-embedded flavor. You do not buy "Amazon Q in QuickSight" as a separate SKU; you turn on QuickSight's generative-BI features by putting users on the appropriate QuickSight Pro tier.
Under the hood, the generative features are powered by foundation models on Amazon Bedrock, AWS's managed foundation-model service. That means Q in QuickSight inherits Bedrock's data-handling posture: your prompts and data are processed inside AWS's security boundary and are not used to train the underlying base models. As with the rest of the Q family, you do not pick the model — AWS manages model selection and routing inside QuickSight.
The practical framing: traditional QuickSight asks you to build the chart and read the chart. Q in QuickSight lets you ask for the chart and ask the chart questions — and it writes the explanation back to you in words, with the visual attached.
Amazon QuickSight = AWS's managed BI service. Amazon Q in QuickSight = the generative-AI layer inside it (build-by-prompt, executive summaries, natural-language Q&A, data stories). It is the BI surface of the Amazon Q family — enabled via QuickSight Pro tiers, not licensed as a separate product.
Read this section once and the rest of the page falls into place. Q in QuickSight bundles four distinct generative capabilities, each aimed at a different moment in the BI workflow — authoring, reading, asking, and explaining.
It helps to map each capability to who uses it and when. Authoring assist and data stories are mostly for the people who build dashboards (Authors). Executive summaries and natural-language Q&A are mostly for the people who consume them (Readers) — though Authors use all four. The four are described below and compared in the table.
An author types what they want in plain English — "show monthly recurring revenue by region for the last 12 months as a line chart," or "create a KPI for week-over-week signups" — and Q in QuickSight builds the visual, picking a sensible chart type, fields, and aggregations. You can then refine it conversationally ("make it a bar chart," "add a trend line," "filter to enterprise accounts") or by hand. It can scaffold whole dashboards from a description, dramatically lowering the skill floor for building BI. This is the capability most often meant by "build dashboards with natural language" in QuickSight.
On a published dashboard, a reader (or author) can request an executive summary: Q reads the visuals on the sheet and writes a concise plain-language narrative of the key takeaways — what moved, which segments drove it, notable outliers and trends — so a busy executive gets the "so what" without interpreting every chart. Because it summarizes the actual data on the dashboard, the narrative refreshes as the data does. This is the fastest way for non-analysts to extract meaning from a dense dashboard.
A reader types a question into a search-style bar — "what were our top 5 products by revenue last quarter?" — and Q answers with an auto-generated visual plus a written answer. This conversational Q&A is grounded in a Q Topic: a curated collection of datasets with friendly field names, synonyms, formats, and default aggregations that teach Q how your business talks about its data. The Topic is what makes the answers accurate; section IV covers building one. Readers can follow up conversationally and pin useful answers into a dashboard.
Authors can generate a data story: a longer, formatted, document-style narrative built from selected visuals and a prompt describing the audience and angle ("a board-ready summary of Q3 performance for non-technical readers"). Q drafts the structure and prose around your data, which you then edit and share — turning a pile of charts into a communicable story. Where an executive summary is a quick on-dashboard recap, a data story is a fuller, exportable narrative artifact.
| Capability | What it does | Primary user | Grounded in | Output |
|---|---|---|---|---|
| Authoring assist | Build visuals / dashboards from a prompt | Author | Your datasets + analysis | A live visual or dashboard |
| Executive summary | Narrate what changed on a dashboard | Reader / Author | Visuals on the current sheet | Short plain-language recap |
| Data Q&A | Answer natural-language questions | Reader / Author | A curated Q Topic | Auto-visual + written answer |
| Data stories | Auto-draft a formatted narrative | Author | Selected visuals + prompt | Editable, shareable story doc |
The generative features are a layer over three things QuickSight already had: your datasets, the SPICE in-memory engine, and (for Q&A) a semantic Topic — wired to foundation models on Amazon Bedrock. Understanding the architecture explains both the security story and why data prep matters so much.
Datasets and SPICE. QuickSight connects to sources — Amazon Redshift, Athena, S3, RDS/Aurora, Snowflake, databases, SaaS connectors, uploaded files — and you model the data into datasets. Many teams import data into SPICE, QuickSight's Super-fast Parallel In-memory Calculation Engine, so queries (including the ones Q generates) return quickly without hammering the source. Every generative answer ultimately resolves to a query against a dataset, so the dataset is the ground truth.
Foundation models via Bedrock. When you write a prompt — to build a visual, summarize a dashboard, or ask a question — Q in QuickSight uses foundation models hosted on Amazon Bedrock to interpret intent and generate the narrative. QuickSight does the deterministic part (running the actual aggregation against your data) and the model does the language part (understanding the request, writing the explanation). That division matters: the numbers come from your data, not from the model, which is what keeps the figures trustworthy even though the prose is generated.
The Q Topic as a semantic layer (for Q&A). Free-form natural-language questions need a map from business vocabulary to data fields. A Q Topic is that map: it tells Q that "revenue" means the net_sales column, that "customers" and "accounts" are synonyms, that dates should default to fiscal months, and how each metric aggregates by default. Without a curated Topic, Q has to guess, and guesses produce confident-but-wrong answers. With a good Topic, Q resolves questions reliably. Authoring assist and executive summaries operate on datasets and analyses directly and lean less on a Topic, but Q&A depends on it.
Permissions and data security. Q in QuickSight respects QuickSight's existing access controls. Row-level and column-level security on a dataset still apply to generative answers, so a user only gets results from data they were already allowed to see — the model does not bypass governance. Because processing runs on Bedrock inside AWS, your data stays within AWS's security boundary and is not used to train base models, consistent with the rest of the Amazon Q family.
Q in QuickSight splits the work: QuickSight runs the real aggregation against your governed dataset (deterministic, exact), and the Bedrock-backed model writes the explanation around it (language). The model narrates; it does not invent the figures. Row- and column-level security still apply, so generative answers never cross a permission boundary.
Turning on Q in QuickSight is quick; making it answer well is the real work. The single biggest determinant of answer quality is the Q Topic. This section walks the setup and the data-prep that separates accurate generative BI from confident nonsense.
At a high level the path is: enable QuickSight and put users on a Pro tier, connect and model your data into clean datasets, build and tune a Q Topic for natural-language Q&A, then pilot with real questions and refine. The steps below expand each part.
A useful rule of thumb: budget more effort for the Topic than for turning the feature on. Teams that skip Topic curation get demos that impress and production answers that mislead. Teams that invest in synonyms, formats, default aggregations, and verified questions get natural-language BI that non-analysts can actually rely on. Executive summaries and authoring assist need clean datasets and analyses but are less Topic-dependent than free-form Q&A.
QuickSight pricing is per-user and split by role, with generative-BI features gated to the Pro tiers. The figures below are representative as of 2026 — always confirm current rates on the AWS QuickSight pricing page, since AWS adjusts tiers periodically.
The role split. QuickSight has always priced by role: Authors build datasets, analyses, and dashboards; Readers consume published dashboards. The generative-BI capabilities introduce Pro variants of both roles. Author Pro (roughly $50 per user per month) includes everything a standard Author can do plus the full generative authoring experience — build-by-prompt, data stories, and building/tuning Q Topics. Reader Pro (roughly $20 per user per month, frequently with a per-session cap so light users cost less) lets a reader consume dashboards and use the consumer-facing generative features: ask natural-language questions, get executive summaries, and interact with data Q&A.
Standard vs Pro. The non-Pro tiers still exist and are cheaper, but they do not include the generative-Q capabilities. A standard Reader can view dashboards; a Reader Pro can also ask questions and get summaries. If your goal is to give a broad audience natural-language access to data, you are budgeting for Reader Pro seats, and that is usually the dominant line item because readers vastly outnumber authors.
SPICE and capacity. Beyond per-user pricing, QuickSight includes SPICE in-memory capacity with paid tiers, and you pay for additional SPICE as your in-memory datasets grow. For most teams the per-user Pro seats dominate the bill, with SPICE a secondary line; very large in-memory deployments shift that balance. Model both: QuickSight bill ≈ (authors × author tier) + (readers × reader tier) + SPICE capacity.
| Role / item | Approx. price | Generative-Q features? | Best for |
|---|---|---|---|
| Reader (Standard) | low per-session / per-user | No | Viewing dashboards only |
| Reader Pro | ~$20 / user / mo (session-capped) | Yes — ask questions, summaries, Q&A | Broad audience that needs NL access |
| Author (Standard) | mid per-user | No | Building dashboards without generative authoring |
| Author Pro | ~$50 / user / mo | Yes — full generative authoring + Topics + stories | Analysts building generative BI |
| SPICE capacity | usage-based | n/a | In-memory data for fast queries |
Generative BI is most valuable where the bottleneck is not the data but the distance between the data and the people who need answers. These are the patterns where Q in QuickSight consistently pays off.
The common thread: Q in QuickSight pays off when there are far more people who need answers than analysts available to produce them, and when the underlying data is clean enough to ground reliable responses. It is less transformative where the hard part is data engineering and modeling rather than access — that work still has to happen first, which is exactly where a build partner and AWS credits come in.
Q in QuickSight does not replace dashboards — it changes how you build and consume them. The shift is from a build-and-read model to an ask-and-explain model. Here is the honest read on what changes and what does not.
Traditional BI is build-and-read. An analyst models data, hand-builds dashboards, and publishes them; consumers read the charts and interpret them, and any new question is a new request back to the analyst. It is precise and governable but gated by analyst time and by each reader's fluency in the tool.
Generative BI is ask-and-explain. Authors build faster from prompts, and consumers ask their own questions and get summaries and narratives in words. The skill floor drops on both sides: you no longer need to know the tool to build, or know the dashboard to extract its meaning. The trade-off is that quality now depends on a well-curated semantic layer (the Q Topic) and clean datasets — the governance work moves upstream into data prep rather than disappearing.
What does not change. The numbers still come from governed datasets, security still applies, and bad data still produces bad answers — arguably more dangerously, because a fluent generated narrative can make a wrong figure feel authoritative. Generative BI raises the importance of data modeling and Topic curation; it does not remove them. The right mental model is augmentation: Q in QuickSight is a faster on-ramp to the same governed data, not a replacement for the discipline that makes the data trustworthy.
A single scannable read on how generative BI changes the workflow versus building and reading dashboards the classic way. Use it to set expectations before a pilot.
| Dimension | Traditional BI (classic QuickSight) | Generative BI (Q in QuickSight) |
|---|---|---|
| Building a dashboard | Drag-and-drop, manual field/chart choices | Describe it in a prompt; refine conversationally |
| Getting an answer | Find the right chart and interpret it | Ask in plain English; get a visual + written answer |
| Understanding what changed | Read every visual yourself | One-click executive summary narrates the takeaways |
| Sharing a story | Hand-write the narrative around charts | Auto-drafted, editable data story |
| Skill floor | Tool fluency (and often SQL) required | Natural language — low floor for build and consume |
| Quality depends on | Analyst skill + clean data | Clean data + a curated Q Topic (semantic layer) |
| Tier required | Standard Author / Reader | Author Pro / Reader Pro |
Situation: The four-person analytics team was a permanent bottleneck. Store managers, merchandisers, and the leadership team funneled every "what were sales by region last week?" and "which SKUs are trending?" question into a ticket queue, and the team spent most of its time pulling ad-hoc numbers instead of doing real modeling. They had clean data in Redshift but no self-service layer, and an off-the-shelf BI tool outside AWS was a non-starter because the security team wanted analytics to stay inside the company's AWS perimeter. They wanted natural-language Q&A and executive summaries for a broad audience, but had no one free to build the QuickSight datasets, Q Topics, and embedded dashboards.
What CloudRoute did: Routed within a day to an AWS Advanced-tier partner with QuickSight and Redshift experience. CloudRoute helped the partner file for AWS credits to fund the engagement: a Bedrock/GenAI proof-of-concept pool to cover the pilot, with Activate Portfolio credits behind it for the broader AWS spend. The partner modeled clean QuickSight datasets over Redshift into SPICE, built and tuned a Q Topic with friendly field names, synonyms, default aggregations, and a set of verified business questions, configured row-level security by store and region, and stood up Reader Pro access plus an embedded dashboard for store managers before a 50-person pilot.
Outcome: Within five weeks the pilot answered the bulk of routine sales and inventory questions in natural language with executive summaries, and ad-hoc ticket volume to the analytics team dropped sharply; the retailer expanded to several hundred Reader Pro seats across stores the following quarter. Roughly the first $45K of AWS consumption across the pilot and rollout was credit-funded. CloudRoute's commission was paid by the partner out of AWS's engagement funding — the customer paid $0 to CloudRoute.
pilot window: 5 weeks · Reader Pro seats at expansion: several hundred · credit-funded AWS spend: ~$45K · cost to customer: $0
CloudRoute routes you to a vetted AWS partner who builds your QuickSight analytics — clean datasets, tuned Q Topics, security, embedded dashboards — and helps secure AWS credits to fund it. Customer pays $0. AWS funds the engagement.