1.1 Data Connections: Live Connections vs. Hyper Extracts

1.1 Data Connections: Live Connections vs. Hyper Extracts

The first design decision in Tableau is choosing the source and the connection mode. Start with the analytical requirement, not a preference for a particular connector. Confirm where the authoritative data lives, how current the view must be, how much data is needed, whether users need offline access, what authentication the source requires, and whether the source supports the Tableau features you intend to use. Tableau can connect to files, relational and cloud databases, and published data sources. Replacing a source later is possible, but matching field names and data types reduces broken references.

Live connections

A live connection leaves the detailed records in the source. Tableau translates a view into queries that the source executes, and the returned results become marks. A new filter, drill, or sort can cause new queries. This makes live a strong choice when users need current source data or when database policies and user-specific credentials must govern every request. It also means performance depends on the database, network, query complexity, concurrency, and source availability.

Live does not mean that every dashboard is automatically fast or that Tableau stores no temporary information at all. It means the governed analytical data is queried from the source rather than refreshed into a Tableau extract. Reduce unnecessary fields and marks, test representative filters, and use the database's own monitoring tools when diagnosing a slow live workbook. A warehouse built for analytical concurrency is a better live candidate than an overloaded transactional application database.

Hyper extracts

An extract is a persisted snapshot stored in Tableau's .hyper format. Tableau queries the extract for the view instead of repeatedly querying the original source. Extracts are useful for portable packaged workbooks, sources with limited analytical performance, and dashboards that can tolerate refresh-based freshness. Extract filters can limit rows before they enter the extract. Hiding unused fields and aggregating data for visible dimensions can also reduce the extract, but aggregation removes detail that later analysis might need.

An extract is not automatically the right answer for every large source. Its refresh duration, storage, security design, and freshness service level must be acceptable. Likewise, live is not automatically fresher if a source itself loads only once per day. Compare the complete data pipeline.

Full and incremental refreshes

A full refresh rebuilds the extract and is the reliable way to reconcile inserts, updates, and deletions. A basic incremental refresh uses an identifying column such as an increasing ID or timestamp and retrieves values after the stored maximum. That approach can miss an old row whose non-key attributes changed and can retain a source row that was deleted.

Current Tableau releases also provide advanced incremental options. With a non-unique identifying key, Tableau can replace the group of rows sharing the current highest key before adding newer groups. With a date or date-time key, a configurable subrange can be re-extracted so recent corrections are replaced. These options improve common cases, but neither turns an incremental refresh into a universal change-data-capture system. A correction outside the replacement group or date subrange still requires a full refresh or a source design that exposes changes through a suitable key. Test the chosen policy with late-arriving, updated, and deleted records.

Source and extract filters

A data source filter restricts data available to every worksheet using that data source. An extract filter restricts rows copied into an extract. Apply an extract filter before creating or refreshing an extract when the excluded rows should not be stored. A worksheet filter acts later and ordinarily affects only its sheet unless its scope is expanded. Do not treat a worksheet filter as a substitute for source-level security: viewers with sufficient download or authoring capabilities might reach data that merely was not shown in one view.

Custom SQL and Initial SQL

Custom SQL defines a logical table from a statement you supply. It is appropriate when the required source-side logic cannot be expressed conveniently with Tableau's data model and a governed database view is unavailable. Tableau normally treats the statement as a query and may wrap it when it generates later analytical queries. That can limit Tableau's ability to prune fields or tables and can make source troubleshooting harder. The source database still chooses its execution plan and can still use indexes; Custom SQL does not inherently disable database indexing. Measure performance rather than assuming every Custom SQL statement is slow.

Initial SQL serves a different purpose. For supported connectors, it runs commands when the connection is established—for example, setting a session variable or initializing a temporary object. It does not itself define the rows shown on the Data Source page. Because connection pooling and reconnects can cause it to run more than once across a session, Initial SQL should be safe to execute whenever Tableau opens the connection.

Practical selection workflow

1. Identify the authoritative source and required tables or published source.
2. Confirm authentication, network access, connector support, and source policies.
3. Choose live when current data and source-enforced behavior outweigh query-load concerns.
4. Choose an extract when refresh-based freshness, portability, or analytical offload is preferable.
5. Apply only justified source or extract filters and retain required detail.
6. For incremental refreshes, document which updates and deletions can be missed and when a full refresh will reconcile them.
7. Validate row counts, key totals, null rates, and representative dashboard results after connection or source replacement.

The defensible answer in a scenario is the connection that satisfies freshness, governance, scale, and operational constraints together. Neither connection mode is universally superior.