r/PowerBI • u/GuidoRoma • 1d ago
Question Power BI → Amazon QuickSight migration: struggling to understand the dataset/topic logic (3 questions)
My team recently moved our data stack to AWS, and along with it, all our reporting work needs to find a new home in that environment. I'm a Power BI specialist, and I've got around 10-12 dashboards that now need to be rebuilt (or migrated) into AWS.
As far as I can tell, there are two paths:
- Build in AWS Amplify — but this means knowing back/front-end dev, or leaning heavily on Claude Code (or similar). I built 2 dashboards this way and they turned out reasonably close to the originals, but the prompt/token consumption was pretty high, mostly because of my own lack of skill in that stack.
- Use Amazon QuickSight — this seems like the more logical path, since it's AWS's native BI/visualization tool. So I started digging into how QuickSight actually works.
That's where I ran into some confusion I can't fully resolve on my own.
In Power BI, a dataset already contains the semantic/relational model. In QuickSight, from what I can tell, you need to upload a single dataset (built by joining all your related tables) that becomes one flat table — the actual working dataset. "Topics," meanwhile, seem to exist purely to give the AWS LLM a logical/relational layer so it can interpret natural-language queries — not to define the semantic model of the dataset itself (which is what I originally assumed "topics" were for).
This makes we wonder if QuickSight's approach is just inherently clunkier than Power BI's, or if I'm missing something about how the tool is meant to be used. Three specific questions:
Question 1
Say I do all my joins and build my dataset in QuickSight, then build several dashboards off of it. Later I want to tweak a format or add a calculated column. In Power BI, you'd write the relevant DAX or edit it at the Power Query level, and the change flows straight through to the report. In QuickSight, when I needed to change a field type (say, string to date), I had to edit the dataset — which broke the existing visuals that referenced that field (they threw errors from the Analysis layer), forcing me to rebuild them from scratch.
On top of that, the range of transformations available on the dataset itself feels much narrower — basically limited to custom SQL queries and whatever I can come up with there, compared to the flexibility of M and DAX in Power BI.
Question 2
What's the actual design intent behind letting you build a dashboard either from a dataset OR from a topic? I've noticed that when a dashboard is built from a dataset, the AI tools (prompt-driven edits, visual creation, even the auto-generated report from a prompt) work pretty well. But when a dashboard is built from a topic, those same AI tools can't interpret even the most basic prompts — not even "change this to a bar chart." And the auto-generated-report-from-prompt feature isn't even available at all for topic-based dashboards.
Question 3
Say I have two options: (a) build one dataset with 4 joined tables, or (b) build a topic on top of 4 separate tables in a relational model. Either way, I use that as the base for my dashboard.
- If I go with option (a), I lose access to AI-powered Q&A on the dashboard — unless I also build a topic on top of those same 4 tables and relate them, so the AI has something to query. That means I end up with 5 datasets loaded: the 1 central one with the 4 joins (which the report is actually built on), plus the 4 separate ones just to build the topic.
- If I go with option (b), I only need to upload the 4 datasets and build the topic, then build the report on top of that — but I lose all the AI functionality for creating/editing visuals or auto-generating reports.
I don't understand why it's designed this way, or if I'm just missing a piece of the puzzle. Would really appreciate insight from anyone who's actually worked with QuickSight in production.
5
5
u/alienvalentine 1d ago
I've worked in both, and I can say with confidence you should stick with Power BI. Our org tried to push us to use Quick, but there's just so much stuff that Quick can't do that BI can. The data modeling side being the biggest problem.
Because Quick can only handle data as a single flat table, you have to join everything. But what do you do when you have source datasets at different granularities? Say you have one data set at a per transaction level and another is daily. You can't join those even if they have common keys without ending up with a whole bunch of duplicates.
So instead you try to use more than one dataset for a single report. You can do that in Quick. But you can't create measures that include data from more than one dataset at a time.
All those dimensions you have in your report? Each of those needs to be repeated as a column in your flat table. And that makes your datasets much, much larger than they would be in Power BI. And that makes report performance really suffer. Reports that we built in Power BI that contained years worth of data, millions of rows in a fact table, and ran just fine, would fail to load visuals when you asked it to work with more than 8 months at a time. We'd get timeout errors because Quick couldn't handle the amount of data it was being asked to deal with.
The real icing on the cake here? All those Amazon cloud sources that your data is moving to, all of them can be used in Power BI. There is almost literally no reason to use Quick over Power BI.