An extract stores a prepared copy of source data for use in a report. It can reduce repeated requests to the original system and make a report feel more consistent, but the copy is only as current as its last successful refresh. Refresh scheduling, row limits, field support, and connector behavior depend on the source and account setup.
What an extract changes
Treat an extract as a managed data product: assign an owner, confirm its refresh schedule, and check what happens when a refresh fails. A report that looks fast but quietly serves a stale copy can mislead its readers.
- Use an extract when repeated dashboard queries are expensive or slow.
- Record the expected freshness window and refresh owner.
- Check whether the extract’s supported fields and row capacity cover the analysis.
What a live connection changes
A live connection sends queries to the connected source as the report is used, subject to the connector’s caching and query behavior. It may provide fresher data, but “live” does not mean every view reflects an instantaneous change. Source updates, connector caches, credentials, and rate limits all affect what appears.
A report with many charts can issue many queries or compete for source resources. Live access can therefore expose data-platform latency to every viewer. Test the dashboard with its expected number of charts and realistic source volume.
- Choose live access when readers need recent source data and the connector supports the workload.
- Check viewer credentials and access controls for the underlying source.
- Monitor query failures, quotas, and the source system’s response time.
Decide by freshness and workload
For a monthly performance review, a refreshed extract may be adequate and easier to operate. For a near-real-time operations view, a live connection may be more appropriate if the source and connector can handle it. A daily report does not become more accurate simply because it queries live data; the source may still update only once a day.
Agree on the maximum acceptable data age before choosing. Then test refresh behavior, opening time, filters, and totals with the actual report. Compare results at a known timestamp so you can tell a freshness difference from a modeling difference.
- Define the freshness requirement in hours or days.
- Measure report response time with representative viewers and filters.
- Document what readers should do if data is stale or a connection fails.
Avoid common operational surprises
Do not assume an extract refreshes whenever a user opens the report, or that a live connection eliminates caching. Confirm the exact behavior of the connector you use. Likewise, do not assume that changing from live to extract fixes a modeling problem: duplicated rows, inconsistent keys, or incorrect aggregation can remain in either mode.
The right setup is the simplest one that satisfies freshness, source load, and access requirements. Revisit it when the source, report audience, or refresh expectation changes.
How did this article land?
Choose one reaction. You can change it anytime.