Skip to content
Notifications
Clear all

Anyone have experience with BI tools that handle >100M rows?

5 Posts
5 Users
0 Reactions
3 Views
(@chrisw)
Estimable Member
Joined: 1 week ago
Posts: 94
Topic starter   [#3321]

Looking at dashboards that crawl with large datasets. Need something that doesn't choke on 100M+ rows.

Tried Tableau with an extract. It works but the initial refresh is a pain. Power BI with DirectQuery on a decent warehouse is okay, but visual rendering can lag. Heard about tools like Apache Superset or maybe Looker with a proper underlying database.

Key points for me:
* Must handle incremental refreshes without rebuilding the entire dataset.
* Direct query performance is critical—don't want to pre-aggregate everything.
* Underlying data store matters more than the BI tool itself. A slow database means a slow dashboard.

What's your stack? Specifically:
* Which BI tool?
* What's the data source (BigQuery, Redshift, Snowflake, etc.)?
* Are you using extracts/live connections?

// chris


metrics not myths


   
Quote
(@mikeb)
Active Member
Joined: 1 week ago
Posts: 11
 

You're spot on about the database being the real bottleneck. At that scale, the BI tool is often just a fancy query builder.

Our setup that works:
- **Tool:** Looker Studio (formerly Data Studio) - it's lightweight and free.
- **Source:** BigQuery, partitioned by date. This is the magic sauce for incremental refreshes.
- **Connection:** Live, always. No extracts. The performance is all on Bigquery's end.

The key for us was setting up our BigQuery tables with incremental partitioning right from the start. That way, every query only scans the date range you need, not the full 100M+ rows. The dashboards stay snappy because Looker Studio just passes the query through.

Have you looked into how your underlying tables are structured? Proper partitioning/clustering can make even a basic BI tool feel fast.


Integrations are my jam.


   
ReplyQuote
(@alexh99)
Eminent Member
Joined: 1 week ago
Posts: 33
 

Agreed on the database being key. I've had success with Looker (the full version, not Studio) against Snowflake. It uses persistent derived tables which can be incrementally built, so you're not hitting the raw 100M rows on every load.

But even with that, we still had to get the clustering keys right in Snowflake to avoid lag. What warehouse are you using right now? That might narrow the tool choice more than anything.



   
ReplyQuote
(@j_carter)
Estimable Member
Joined: 4 months ago
Posts: 113
 

You're right that the database is the main event. We're in a similar spot, migrating our CRM data and hitting those same lag issues.

We ended up with Metabase on top of BigQuery, with a very similar approach to the partitioning mentioned below. The biggest shift for us was rethinking our materialized views as incremental tables. Instead of one massive refresh, we have a process that appends new/changed rows daily. It made all the difference for direct query performance.

What's your current data warehouse? That choice might lock you into certain BI tools more than you'd think.


Migration is never smooth.


   
ReplyQuote
(@lindak)
Eminent Member
Joined: 1 week ago
Posts: 19
 

Totally agree on the clustering keys being a make-or-break detail. We ran into that with Looker on Redshift a while back. Even with PDTs, if the underlying table isn't clustered well for your common query patterns, you're just waiting for those massive full scans.

That's partly why we've been experimenting with some newer tools that do smarter, automated indexing behind the scenes. Have you guys looked at any of the "headless BI" or semantic layer options? Sometimes offloading that logic from the warehouse itself can help.


Happy hacking!


   
ReplyQuote