I used QuickSight, now Amazon Quick Sight, as the first BI layer of a production system: a production forecasting system, over a data lake on S3 and Athena. It did the job for a while. Connecting it to data that already lives in AWS is genuinely convenient, and that's the only part I'd praise.
Everything after the connection was a pain to work with. The dashboards are built by clicking in a console, so they sit outside the code, outside review and outside the infrastructure that rebuilds everything else. They look like QuickSight, not like your product. And every new question means another round in a tool only one or two people on the team know how to drive.
What changed my mind for good is agentic programming. A chart in your own app used to be expensive to build, and a BI tool was the shortcut. Now Claude Code writes a dashboard over Athena or DuckDB in an afternoon, in your design, under your app's access rules, versioned and reviewed like any other code. We replaced QuickSight that way, and the new dashboards are far better than the old ones.
So my advice is simple: don't start with QuickSight. Put the data in a lake, query it with Athena or DuckDB, and have an agent build the dashboards your people actually need. If you already run QuickSight and it works, keep it, and build the next dashboard in your app instead.
Don't use it when
- Dashboards for your customers or your staff inside your own product: you want them in your app, in your design, under your access rules.
- Anything that has to be versioned, reviewed and rebuilt from the repository like the rest of the system.
- A team that will ask for one more chart every week: with an agent, each one is a small pull request instead of another session in a BI console.
In my words: what hurts
- I used QuickSight as the first reporting layer of a production forecasting system. It was good while it lasted.
- Connecting it to data that's already in AWS is convenient. Everything after that is a pain in the neck.
Gotchas, with fixes
Gotcha: Dashboards built by clicking in the console live outside the repository: no review, no history next to the code, and no clean way to rebuild them in another environment.
Fix: If you must keep it, export and version the definitions through its APIs. Better: build the dashboards in your app, as code.
Provisioning
Official Pulumi package · Official Terraform provider
@pulumi/aws quicksight.DataSource, DataSet, Analysis and Dashboard. The data sources are easy to declare; the dashboards themselves are usually built in the console.
Use instead
Bespoke dashboards and charts in your own app, built with Claude Code over Athena, DuckDB or your database.
Alternatives
- Claude Code Bespoke dashboards and charts in your own app: the agent writes them, you review them.
- S3 + Glue + Athena The queries behind the dashboards, over the data lake.
- DuckDB Fast queries for an app's own charts, on the same Parquet files.
Worked examples
Where it fits
- A data lake: Don't.
Convenient to connect, painful to live with. Dashboards built by clicking in a console, that your users can't shape and your repository can't hold.
Instead: Claude Code
Sources
Last reviewed by Nicolas Dao