Build1 publisher2 min readPublished
Amazon Quick apps re-run agent-written SQL on governed Quick Sight data each time a viewer opens them
Amazon Quick's AI-built apps now query governed Quick Sight datasets, in SPICE or Direct Query mode, each time someone opens them. Queries run under the viewer's identity, so the row- and column-level rules already on a dataset decide what each person sees.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Until this release, any Quick Sight dataset figures in a Quick app were baked in at build time, while connectors such as Jira, Slack and Google Drive already ran at view time.
- The agent picks the relevant curated datasets itself and writes the SQL during the build, and the published app re-runs that same SQL whenever someone opens it.
- Builders approve each dataset during the build, and every viewer must consent to each dataset the first time they use it.
- Apps using live datasets are limited to authenticated Quick users, and AWS says the ban on anonymous or public access is enforced at multiple layers.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Builders and viewers both need at least the Reader Pro role, so every person added to an app's audience is another Reader Pro seat to provision.
- decision Each extra dataset in an app adds a first-use consent for every viewer. Builders who want a smooth rollout have a reason to keep each app on as few datasets as possible.
- exposure Each live-data app shows exactly the rows its dataset's rules allow. A mistake in one dataset's row-level security therefore reaches every app built on that dataset.
An app built this way answers one fixed question [1]. In the post's support example, someone wants tickets closed last week by region. Today that person rebuilds a chart and pastes it into Slack every week [11]. That question suits a stored query because it repeats and only the answer changes [1]. Anyone who has owned that weekly chart will not miss it. A breakdown by product instead of region means changing the app, because the build-time SQL is all the published app runs [4][1].
How current the answer is depends on the dataset under it [2]. The post supports two modes: SPICE, which it describes as in-memory, and Direct Query [3]. AWS writes that the app re-runs the same SQL on every open, "so the numbers are always current" [12]. For a SPICE-backed app, that holds only as far as the in-memory copy is current [2].
Every open sends a fresh query to the dataset [6]. A team that reloads a dashboard through a shift sends one query per person per reload [6]. The post does not give latency or per-query cost figures. Nothing in it shows whether a busy Direct Query source keeps up when a whole team opens the same app at once.
AWS sizes the benefit with its example company, AnyCompany, whose regional sales leaders review deal renewals [10]. AWS says the workflow "would typically take a month's effort" because the right data has to be pulled for each customer [10]. With live data, it says, a sales leader can build the app from a dataset they already have access to and share it without waiting for IT [10]. The month is an estimate for an illustrative company. It applies to a real team only if that team's delay really was pulling per-customer data, which is the step AWS names as the slow one [10].
Tying access to the viewer is the right design, and I would have made the same call. The app holds no row filter of its own for the agent to write or get wrong [4]. It inherits whatever row-level and column-level security the dataset already has, and the post allows datasets with or without either [9][4].
What to watch
- Whether AWS publishes limits for the query guardrails the post mentions, and latency figures for apps on Direct Query sources.
- Whether a published app can regenerate its stored SQL when the dataset's schema changes, or has to be rebuilt.
- Whether Reader Pro stays the minimum role for viewing a live-data app, or a lower viewer tier gets access.