Hire QuickSight Developers

QuickSight earns its place when the data already lives in AWS and the alternative is licensing and operating another platform beside it. Serverless capacity, per-reader pricing and native integration with Athena, Redshift, S3 and IAM make it a pragmatic choice, particularly for embedding analytics into a product a customer already logs into.

In this tool the reporting decisions and the infrastructure bill are the same decision. That is the honest difference from the desktop-first products: a dashboard here is a query pattern against services that charge by what they scan and how much they hold in memory, so an analytics design that ignores cost is not a design.

The first decision: in-memory, or query the source

Loading a dataset into the in-memory store gives fast, predictable dashboards and decouples readers from the source system, at the price of staleness between refreshes and a size ceiling per dataset. Querying the source directly gives freshness and no duplication, at the price of every reader’s interaction becoming a real query against a warehouse or a query engine.

The rule we work to is that the in-memory store is the default for anything read by many people, and direct querying is for the small number of views where the number on screen has to be current. What does not work is choosing per author’s preference, because that produces an estate where nobody can predict either latency or cost.

Where refreshing the whole dataset stops being viable, incremental refresh over a time window is the answer, and it needs a source column that reliably marks when a row last changed. That requirement usually lands back on the data engineering team, and it is better raised in week one than in month four.

Cost is decided upstream, not in the dashboard

When the source is a query engine billed by data scanned, the levers are all in the storage layout: columnar files rather than row-oriented ones, partitioning on the columns people actually filter by, and files that are neither enormous nor tiny. A dashboard filtering on a column the data is not partitioned by will scan everything, every time, for every reader.

An unoptimised scan repeated on a schedule is a bill, not a bug report — and it will not appear in any error log. The habit worth hiring for is checking what a query costs before putting it on a refresh schedule.

Embedding and multi-tenancy, done properly

This is where the tool is most often chosen and most often misused. There are two embedding models — one for users who exist as identities in the account, and one for anonymous readers where tenancy is carried in the session — and they lead to genuinely different security designs.

Row-level security has to be enforced by the data, through a rules dataset or session tags, never by a filter set on a visual. A filter is a default; a determined reader can change it. Anyone proposing tenant separation by dashboard filter should be corrected in the interview, because that is the mistake that becomes a disclosure.

Assets belong in version control

The service encourages you to build by clicking, and a clicked dashboard exists in exactly one place with no history. Datasets, analyses, dashboards and permissions can all be defined as infrastructure, and doing so is what makes a development-to-production promotion, a code review of a permission change, or a rollback possible at all.

It is more work up front and it is the difference between an analytics estate and a collection of artefacts.

Where QuickSight is the wrong choice

Where the data is not in AWS. The integration advantage disappears and you are comparing feature by feature against tools with far deeper modelling and visualisation.

Where analysts need genuinely open-ended exploration, or where the semantic modelling requirements are heavy — this is a leaner modelling layer than its main competitors, and pretending otherwise disappoints people three months in. And where the requirement is a pixel-exact printed document.

What we interview for

Ask about embedding and about cost, because those are the two places this tool is usually chosen and usually misused. How did they isolate tenants, what did row-level security cost them in complexity, and how did they keep refreshes and scans within budget. Ask also what they would not attempt in QuickSight, since honest limits are a good sign of real use.

Then one practical question: how is a dashboard promoted from development to production in your setup. If the answer is that someone rebuilds it, they have not run this at scale.