All cheat sheets
Operational Efficiencycheat sheet

QuickSight SPICE Capacity

SPICE bills on capacity allocated, not used — and allocations only drift upward. Auditing datasets (delete unused, trim SELECT *, pre-aggregate fact tables) then lowering the allocation routinely cuts the second-largest QuickSight line by 40–60%.

Last reviewed: July 11, 2026

TL;DR: SPICE — the in-memory engine that makes QuickSight dashboards feel instant — is sold in 10 GB blocks at ~$0.38/GB-month and bills on what you allocated, not what you loaded. Allocations get bumped for big ingests and never lowered, so year-old deployments routinely pay for 40–60% empty space. The audit is 15 minutes: delete unused datasets, trim SELECT * imports to the columns dashboards use, pre-aggregate fact tables, then lower the allocation.

The numbers

  • $0.38/GB-month (Enterprise), 10 GB included per Author; 800 GB allocated with 220 GB used = **$220/month for empty memory**
  • Field example: 18 months of drift to 1.2 TB allocated ($410/month) → deleted 18 stale datasets, trimmed three SELECT * imports (410 GB holding 60 GB of used columns), pre-aggregated a 240 GB history table to 8 GB → **$140/month**, no visible change to any dashboard
  • The pre-aggregation trophy: a 180M-row shipments table (140 GB SPICE) whose dashboards only ever grouped by day/region/carrier became an 8,500-row rollup — 1.5 GB, refreshes in 12 seconds instead of 45 minutes, charts 15× faster

Do this

  1. Check Allocated vs Used (Manage QuickSight → SPICE Capacity). The gap is money; note it before touching anything.

  2. Sort datasets by SPICE size, audit the top five:

    • Untouched in 60–90 days → delete.
    • Wide import? Trim to dashboard-needed columns at the dataset level (filtering in the analysis doesn't help — the bytes are already imported).
    • Dashboards always aggregate it? Build the rollup table in the warehouse and point SPICE at that.
    • Queried monthly at most? Flip to Direct Query and stop storing it.
  3. Lower the allocation — the step everyone forgets; cleanup without it saves nothing. Come down in 10–20% steps, keep ~20% headroom (a ~95%-full allocation can break refreshes).

  4. Stagger refresh schedules (50 datasets at midnight hammers the warehouse) and use incremental refresh where the source supports it — that's a source-side query-cost saving on top.

  5. Calendar a quarterly repeat. Allocations only drift one direction without it.

Gotchas

  • Allocation ≠ usage is the whole game — AWS lets you decrease, but only to current-usage-plus-buffer, and never does it for you.
  • SPICE compresses 2–5× on ingest — size against the console's post-compression number, not the warehouse table size.
  • Direct Query isn't free either: it shifts cost to per-query charges and warehouse load; the 80/20 split (SPICE for interactive, Direct Query for rare/real-time) is the usual sweet spot.
  • Real-time needs (< ~15 min freshness) can't use SPICE regardless of cost.
  • Very large single datasets (500M+ rows) fight the platform — the fix is pre-aggregation, not more capacity.

Skip this if

  • Total usage sits under the Authors' included allocation — nothing to optimize.
  • The deployment is new — do this at month 6, not week 1.
  • Readers dominate the bill — do reader pricing first; SPICE is usually line two.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing QuickSight SPICE capacity for waste. Use the AWS CLI
with READ-ONLY credentials. Do not create, modify, or delete anything.

1. Allocation vs usage: aws quicksight describe-account-settings /
   the console SPICE capacity page show allocated vs used GB per
   region (CLI coverage is thin — note where console confirmation is
   needed). The gap × $0.38/GB-mo is the immediate finding. Authors
   include 10 GB each of free capacity.
2. Dataset inventory: aws quicksight list-data-sets + describe-data-set
   per id — capture ImportMode (SPICE vs DIRECT_QUERY),
   ConsumedSpiceCapacityInBytes, LastUpdatedTime. Sort by size; top 5
   are usually 80% of usage.
3. Per large dataset, flag:
   a. Stale: no refresh/access in 60–90 days → delete candidate.
   b. Wide imports: column counts far beyond what dashboards need
      (SELECT * signature) → trim at dataset level.
   c. Aggregation candidates: multi-GB fact tables whose dashboards
      only ever show grouped views → pre-aggregate at the source
      (typical 100–5000× size reduction).
   d. Rarely-queried big datasets → convert to Direct Query.
4. Refresh hygiene: refresh schedules clustered at the same hour
   (source-DB hammering), failing refreshes, full refreshes where
   incremental is supported.

Report: allocated vs used with $ of empty allocation, dataset table
(name | GB | mode | last used | recommendation), projected post-
cleanup allocation and $/mo, and the reminder that allocation must be
manually decreased after cleanup. Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The QuickSight SPICE Capacity walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough