Drop a file. Get a database.
Or connect the one you already have. Both end up behind the same interface, so a widget cannot tell the difference and neither can the person reading it.
Three ways in
Bring a file, a database, or an account
Real tables, not a spreadsheet pretending
Columns with types, forms that write to them, and a designer for the shape. Drop a spreadsheet and one arrives already filled — the columns are read from the file rather than guessed at by you.
PostgreSQL, MySQL or MongoDB
Connected read-only. Two on Pro, ten on Team. Read-only is the point rather than a limitation: nothing dash-b does can write to your production data, because it was never given the ability to.
One catalogue for every source
Connectors, OAuth accounts, and your own WordPress site — whose posts, pages and media arrive as something a widget can read, without a plugin rewriting your theme.
Your readers
Decide what a user is made of
Name the fields, choose the types, allow the uploads, and the profile form that writes them appears. A dashboard with one reader does not need this. A dashboard with a hundred does, and it is the difference between a page and a product.
The honest part
What happens when the data is not there
A tile that cannot reach its source says so.
It does not render an empty chart, and it does not quietly show you last week's numbers as though they were today's. This matters most in an exported copy, where half the services are not there at all — you always know which half you are looking at.
Your data stays yours, including on the way out.
Export a design and it takes its shape with it. Export the whole designer and it takes the connections too. Neither has ever needed a plan.