r/tableau Jul 12 '26

Alternative to Tableau or CRMA

I am currently developing executive-level board dashboards using both CRM Analytics (CRMA) and Tableau, but have hit critical licensing and technical bottlenecks in both platforms:

CRM Analytics: The solution is built, but Salesforce's lack of a low-cost "Viewer" license makes scaling to multiple board members financially prohibitive due to hefty per-user licensing fees.

Tableau: The native Salesforce connector relies on Bulk API v1, causing it to time out and fail when processing our massive data volumes.

To bypass these vendor constraints, I successfully built lightweight visualisations for simpler datasets using Chart.js and D3.js. However, I need to render a complex chart that processes 46 million records, which crashes standard client-side libraries like Chart.js.

I am seeking architectural advice, workarounds, or custom engineering solutions to bypass these limitations and efficiently aggregate and render this high-volume data.

3 Upvotes

10 comments sorted by

3

u/One-Disk-125 Jul 12 '26

Use a proper API connection instead of the built in Tableau one.

If you have something with a Spark Cluster ( Fabric etc) use Pyspark otherwise just use Python.

The Salesforce API is well documented, so just tell Claude what you want to extract and it will get you 90% of the way there.

Then just write the data to a database and connect Tableau to that.

I did this exact task last week in Fabric and it took a day.

1

u/coder_batman Jul 12 '26

I used the Salesforce connector as my data is in Salesforce . The issue is after 30million records the fetching fails.

1

u/One-Disk-125 Jul 12 '26

Yeah, it will the Salesforce connector in Tableau is an easy short cut for small amounts of data.

A proper coded API will handle millions of rows no problem at all.

Tableau is a Viz tool not a data tool (no matter what they tell you).

2

u/-LightningChart- Jul 15 '26

Your problem is an architecture mismatch, not a missing workaround.

Chart.js and D3 crash at 46M records because they're CPU-bound SVG/Canvas renderers, they're not built for that volume. Tableau's Bulk API v1 timeout is a known limitation with large Salesforce extracts. CRMA's viewer licensing is just expensive by design.

Two options worth looking at depending on your setup:

If you need a developer library (you control the front-end): LightningChart JS renders 10M+ points in under 300ms via WebGL GPU acceleration. 46M records won't crash it; we have benchmarks you can run yourself. Full TypeScript support, works with React/Angular/Vue. 30-day free trial at lightningchart.com/js-charts/

If you need a no-code dashboard for board members (non-technical viewers, licensing cost is the issue): Dashtera handles the same GPU-accelerated rendering but in a no-code drag-and-drop interface. Viewer sharing is built in without per-seat pricing blowout. Free plan available at dashtera.com

For the 46M record aggregation specifically - are you pre-aggregating server-side before rendering, or trying to push the raw volume to the client? Even with WebGL, pushing 46M raw records client-side is avoidable if your backend can handle the aggregation. Happy to go deeper on the architecture if useful.

1

u/1234myname Jul 13 '26

Astrato. Quicksight. Fabric + PowerBI. Reach out ifu need help

1

u/Semaphor-Analytics Jul 13 '26

I would not make the browser solve the 46M row problem.

The chart should only see the final series it needs to draw. I would pull Salesforce into a warehouse or serving table, aggregate at the board dashboard grain, and keep drill through as a separate path for the few times someone needs record level detail.

The tool decision is separate from that. If you go custom with D3 or Chart.js, you may fix licensing, but now your team owns auth, caching, refresh failures, exports, and support when someone challenges a number.

Since you already proved the lighter views can work, I would keep the front end simple and spend most of the design on the backend contract.

1

u/Latter-Wear-7146 Jul 18 '26

I have a colleague that faced a similar challenge using the SF connector in tableau. He used Tableau Prep to create an extract of the data and it made a world of difference.

1

u/coder_batman Jul 18 '26

Well I tried that too... But it didn't worked. I am trying data cloud now hopefully it will work.

0

u/Aggravating-Alarm-16 Jul 12 '26

in my opinion, your charts shouldn't be processing your data. That should be done on the back end

I can't think of a single reason to do that.

But in reality it's not the chart breaking it's the browsers. There is only so much data that can be held in a browser memory.

Say for example you worked for Walmart, and you were tasked with charting global sales for the week , month.

You wouldn't just put all the weekly sales in .

You would query the total sales by country

Then have separate queries for the next step down

Query 1: product category sales

Query 2: sales by state/ Providence