AWS Quick Sight embedding – lessons on dynamic filters, pivot saves, RLS & SPICE vs DirectQuery?

Q&A
1

Hi everyone,

Project context: We’re migrating a multi-tenant Java/Angular reporting app to Redshift + embedded Quick Sight. This is for a 100M+ row fact table that grows by 3-4M rows/day, and it’s the first large-scale Quick Sight embed for our team.

We’d love any “war stories” or insights you have on the five gaps below please:

  1. Dynamic filters – We need to use the JS SDK to push tenant_id and ad-hoc date ranges from our parent app at runtime. Is this feature rock-solid or brittle? Any unexpected limits?
  2. Pivot + bookmark persistence – Can an end-user create and save a custom pivot layout as a “bookmark” inside the embed, without having to go to the main QS console?
  3. Exports – We have a hard requirement for both CSV and native .xlsx exports directly from the embedded dashboard. Are there any hidden row caps or API throttles we should know about?
  4. SPICE vs. Direct Query – For a table of this size, does an hourly incremental SPICE refresh work reliably, or is it painful? Any horror stories about Direct Query queueing under heavy concurrent use?
  5. Row-level security at scale – What is the community’s consensus or best practice? Should we use separate Quick Sight namespaces per tenant, or a single namespace with a dynamic RLS rules table?

Links, gotchas, or clever workarounds—all are welcome. We’re a small data-eng crew and really appreciate you sharing your experience!

Thank you very much for your time and expertise!

2

Hello @Martin2 , welcome the Quick Sight community!

  1. For filtering from an app to an embedded dashboard you can use the following:
    GitHub - awslabs/amazon-quicksight-embedding-sdk: A SDK to help users embed QuickSight dashboards on other pages.
    You can also take advantage of CustomSQL and dataset parameters.
    Using dataset parameters in Amazon QuickSight - Amazon QuickSight
    Biggest down side to dataset parameters is that it has to be Direct Query which is slower than SPICE.

  2. Registered users should have bookmarks that are sticky. Can you clarify what you mean by custom layout for pivot table? As in the user will filter or hide show rows or they will actually change the pivot table?

  3. There are data limits on the exports from tables/pivot tables:
    Exporting data from visuals - Amazon QuickSight

  4. SPICE is pretty robust and the problems we have had in the past with refreshes failing is more to do with the query rather than anything specific with SPICE. Direct Query can slow down if you data source is slow or times of high traffic. We honestly avoid Direct Query unless we have a requirement for real time or near real time data.

  5. I would recommend using namespaces for multi-tenant set ups. That being said RLS is reliable in Quick Sight so it just comes down to how your org likes to manage groups.
    Supporting multitenancy with isolated namespaces - Amazon QuickSight

Hope some of this was helpful!