I have a table with over 100 columns. I am getting warnings about model size, and the file is becoming huge. Should I be removing unused columns, or does Power BI handle them effectively if they aren't used in visuals? I want to optimize my file size before publishing to the service.
Unused columns in a Power BI model must be removed at the source because the VertiPaq engine consumes memory for every column in the schema, regardless of whether those columns are utilized in specific visuals.
6 answers
You should prioritize removing those columns to maintain performance and avoid hitting refresh limits.
- Use Power Query to drop columns at the source rather than just excluding them from the report
- Verify if your data model uses unnecessary high-cardinality columns that serve no business purpose
- Standardize your data ingestion to pull only what is required for current business intelligence reporting
You need to cut those columns immediately because Power BI's VertiPaq engine loads everything into memory regardless of whether they are visible on your report canvas. I once saw a model crash a production-grade gateway because an unused, high-cardinality ID column was hogging 4GB of RAM, effectively neutralizing all our performance optimization efforts.
Yes, your schema is too wide and likely violating core normalization principles.
Removing unused columns is essential because VertiPaq compression is column-store based; unreferenced data still consumes memory and degrades scan performance. I previously migrated a 200-column finance dashboard where shedding 140 unused fields reduced the model size by 85 percent and increased query response time by an order of magnitude.
Keeping 100 columns is a recipe for disaster when you scale.
You are essentially choosing between memory efficiency and convenience, but convenience is a luxury you cannot afford in an enterprise production environment. Keeping unused columns is a trade-off where you sacrifice your data model footprint for lazy development habits, which will eventually manifest as refresh failures or slow visual rendering once your user base grows.
That model is bloated and needs a trim.
Power BI is not smart enough to ignore columns sitting in your data model, so unless you delete them, they live in your RAM forever. Clean it up now or deal with the performance lag later when your datasets inevitably start failing their scheduled refreshes.
The core issue here is how the Power BI engine processes data at rest and during execution. When you import a dataset, Power BI reads the entire schema into the VertiPaq storage engine. This engine uses a columnar database structure, which is highly efficient for analytical queries but strictly requires that every column defined in your schema occupy space in memory. Even if you do not drag a field into a visual, it still undergoes dictionary encoding and compression during the load process, contributing to the overall file size and memory footprint of the instance.
If you have over 100 columns, you are likely carrying metadata, internal audit tags, or redundant foreign keys that do not contribute to your KPIs. The ingestion layer should ideally be treated as a filter; you want to reach a state where your Power Query script looks something like Table.SelectColumns(Source, {List of columns}). By keeping the model thin, you decrease the vertical scan time required for DAX measures to iterate over your fact tables.
Ultimately, a wide schema introduces unnecessary noise into the model metadata. This makes the report more difficult to maintain for other developers and increases the complexity of the data lineage. You should perform a systematic audit of your visuals and purge any column that does not serve a specific, documented business requirement. Your performance metrics will reflect this change almost immediately upon the next refresh cycle, as the reduced memory overhead will allow for faster data throughput and better concurrency.
