Faster Tally Reporting. No Complex Keys Required!
Where the RAM goes, which CPU cores do the work, and why a report that is slow in Tally answers in a click once the same data sits in Power BI. Two ways to set it up, and when each one fits.
"Sales by month by party, three years." Tally, SQL Server and Power BI all hold data in memory. What differs is what they keep there, and how many cores work on one question.
In RAM: The loaded company, as raw vouchers and masters.
Work per click: Walks the vouchers and adds them up again.
Cores on one report: One; a report is never split across cores.
More RAM: Helps until data and users fit; then nothing more.
Where the wait is: Every report, every time.
In RAM: Data pages cached from disk, plus indexes and any summary tables built.
Work per click: Plans the query, then reads indexed rows or pre-built totals.
Cores on one report: Several, when the query plan goes parallel (edition and settings decide how many).
More RAM: More of the books stays cached; fewer disk reads.
Where the wait is: First run of a query, until the data is cached.
In RAM: Every column, compressed; each repeated name stored once.
Work per click: Scans only the 2–3 compressed columns the chart needs.
Cores on one report: One per data segment for the scan; one for the DAX formula logic.
More RAM: Lets a larger dataset be loaded; the dataset must fit.
Where the wait is: Only at refresh.
Tally uses RAM too. It loads the company, and more RAM helps until the loaded companies, every user's session and the data files all fit in memory. On a busy multi-user server that often cures a real slowdown, because Windows stops swapping to disk. Past that point extra RAM has nothing left to hold: Tally keeps no pre-added totals, so each report still walks the vouchers on one core.
Power BI Desktop runs its own in-memory analytical engine as a background process on your machine. When you open a report, the whole imported dataset is loaded into RAM in compressed form. Every measure and every chart is calculated there. Nothing goes back to Tally, and nothing is read from disk.
One click goes through four steps:
You click a slicer. Each chart on the page sends its own query to the engine, and several charts query at the same time.
The formula engine plans it (one core). It reads the measure's DAX logic and the active filters, and breaks the work into simple scan requests. This part runs on a single thread.
The storage engine scans (many cores). It scans the compressed columns in RAM and adds them up. Each data segment is scanned on its own core.
The result comes back. The small result is combined and drawn. Repeated scans are served from the engine's cache.
A fast measure keeps most of its work in step 3. A slow one drags work into step 2, for example by testing conditions row by row, which leaves one core doing it all.
It reads only what the chart needs. Data is stored column by column. "Sales by month" reads the date and amount columns and skips everything else in the voucher.
Tally data compresses well. Ledger names, parties, voucher types and GSTINs repeat thousands of times. Each distinct value is stored once, and every row keeps a small code.
The adding-up happens in RAM. Scans run over compressed codes already in memory, not over records read from disk or rebuilt for each report.
Joins are prepared at refresh. Links between ledgers, parties, items and dates are mapped once when data loads. A click filters codes; it does not re-join tables.
Scans use several cores. Large tables are split into segments and scanned side by side.
Power BI stores each imported table in segments of about one million rows. A scan gives each segment its own core, then adds the partial totals together.
Usually under a million voucher lines, so one segment and one core. It is still fast, because the scan is over compressed codes already in RAM. For a single company the speed comes from compression, not from parallelism.
Several million voucher lines, so several segments, each scanned on its own core at the same time. The wait grows far more slowly than the size of the books.
Several tables load at the same time, each on its own core. Parsing the data extracted from Tally is the heaviest step, and memory use peaks here.
Scans run in parallel by segment, and the DAX formula logic runs on one core. Memory stays at the size of the compressed dataset plus working space.
No separate database server. Fits one analyst or a small team, a handful of companies, and refresh when you need it. The whole dataset must fit in that machine's RAM. Sharing online needs Microsoft Power BI licences, and a Pro workspace caps a dataset at 1 GB.
Extract from Tally. RAM: Tally's own loaded company. Cores: one per Tally request. Parallelism: limited by Tally; the slowest link, run only at refresh.
Load into Power BI. RAM: peaks while data is parsed and compressed. Cores: one per table being loaded. Parallelism: several tables at once.
Report (DAX queries). RAM: the compressed dataset, fully in memory. Cores: one per segment for scans; one for formula logic. Parallelism: grows with data size; several charts query at once.
For many users, many companies or years, one set of numbers for everyone, scheduled refresh, and history kept outside the report file. SQL Server caches the books in RAM, can split a heavy query across several cores, and holds pre-added summary tables. Power BI then imports from SQL Server and answers clicks in its own RAM exactly as on the desktop tier. Tableau's extracts use its own columnar, multi-core engine. A live connection instead sends every click to SQL Server.
Extract from Tally. Same as the desktop tier, run unattended on a schedule.
SQL Server. RAM: data cache holds the books; summary tables hold pre-added totals. Cores: several on a heavy query (Express: max 4). Parallelism: parallel query plans; many users side by side.
Power BI import. As the desktop tier; can refresh only what changed.
Tableau extract. Columnar extract in memory, using multiple cores. A live connection instead sends each click to SQL Server.
Mind the edition. The free SQL Server Express uses at most 4 cores and about 1.4 GB of memory for its data cache, with a 50 GB database limit in the 2025 release. Larger books need Standard or above.
It depends which part of Excel. Worksheet formulas and ordinary pivots store and recalculate each cell separately, each lookup scans its range again, and a sheet stops at 1,048,576 rows. Power BI is far faster than that. Excel's Data Model, however, uses the same in-memory engine as Power BI, so its speed is comparable. Power BI adds report pages, sharing and scheduled refresh around it.
On a call we reconcile a month against Tally's own Sales Register, click through the full dataset, and show the report still working with the network switched off. Bring your questions about RAM, cores and edition sizing.
Product limits as published by Microsoft, September 2026. Behaviour varies by Tally release, hardware and data shape.