The Easiest Way to Snapshot Tableau's PostgreSQL Repository Over Time

Jung Kim — Wed, 15 Jul 2026 08:38:28 +0000

Tableau's PostgreSQL repository tracks event history well — historical_events will tell you plenty about what happened and when. But content and state tables like _workbooks and _datasources only reflect current state; they don't retain past values for things like storage size or content counts. Getting a trend line out of that might sound like it needs a script, a cron job, or a separate table to accumulate snapshots over time. It doesn't — Tableau Server can do all of that for you.

The pattern

Write a SQL query that returns the point-in-time metric you care about (storage, content counts, whatever).
Publish it to Tableau Server as an extract.
Set the extract's refresh type to incremental refresh, instead of full refresh.
Put it on a schedule — daily, weekly, monthly, whatever cadence matches how fast the thing you're tracking actually changes.

Each scheduled run appends new rows instead of overwriting the extract, so the extract itself becomes your history table. No external script, no cron job, no separate database to maintain — Tableau Server's own scheduler is doing all the work you'd otherwise build yourself. (Tableau's own docs on configuring incremental refresh are worth a look if you haven't set one up before.)

The use case

I use this to track server storage over time (more on that in another post), but the pattern generalizes to almost any "how has this changed" question you can answer with a single query: content counts, stale content trends, license utilization — anything where you'd otherwise be tempted to stand up a mini data pipeline just to get a time series.

Things to know before you use this

Incremental refresh only works cleanly if each run is genuinely additive. The query needs to produce new rows each time (e.g., a snapshot keyed to CURRENT_DATE), not update existing ones. If your query's output could change retroactively for a past date, incremental refresh will get out of sync with reality — full refresh or a different approach is a better fit in that case.
This trades granularity for simplicity. You get whatever snapshot frequency your schedule uses — daily is common — not a continuous audit trail of every change as it happens. For most trend-watching use cases that's a fine tradeoff; if you need to catch every individual event, you're back to querying historical_events directly instead of snapshotting a summary.
Keep the query itself simple. The whole appeal of this pattern is that Tableau Server does the heavy lifting on scheduling. If the underlying query gets complicated enough that it needs its own maintenance, some of that simplicity advantage starts to erode.

Tracking Tableau Viewership with PostgreSQL

Jung Kim — Fri, 03 Jul 2026 19:36:23 +0000

Tracking Tableau Viewership with PostgreSQL

Tableau's native "Who has seen this view?" panel is a flat list — no trends, no way to tell if usage is real or just the publisher checking their own work. With direct access to the Tableau PostgreSQL repository, you can do a lot better: turn raw access events into aggregated viewership data your dashboard creators can actually act on. Here's the query I use to power that.

The SQL

WITH access_events AS (
    -- Pull only "Access View" events from the last 90 days
    SELECT
        he.id,
        he.created_at,
        he.hist_view_id,
        he.hist_workbook_id,
        he.hist_actor_user_id
    FROM historical_events he
    JOIN historical_event_types het
        ON he.historical_event_type_id = het.type_id   -- filter to the event type we care about
    WHERE het.name = 'Access View'
      AND he.created_at >= NOW() - INTERVAL '90 days'
)
SELECT
    w.name                           AS workbook_name,      -- current workbook name, from the live content table
    hu.friendly_name                 AS viewer_name,         -- NULL when the workbook has zero views
    COUNT(ae.id)                     AS view_count,          -- 0 when no matching access events
    MAX(ae.created_at)               AS last_viewed          -- NULL when never viewed
FROM _workbooks w                                            -- drive from the full content table...
LEFT JOIN hist_workbooks hw ON hw.workbook_id     = w.id      -- ...so workbooks with no history still show up
LEFT JOIN access_events ae  ON ae.hist_workbook_id = hw.id
LEFT JOIN hist_users hu     ON hu.id               = ae.hist_actor_user_id
GROUP BY w.name, hu.friendly_name
ORDER BY w.name, view_count DESC;

The use case

I built this as the backbone of a self-service "Viewership Analytics" dashboard — KPI tiles, a time-series trend, top-viewers ranking, and a detail table with recency color-coding. The goal was to give dashboard creators direct visibility into how their own content is actually being used, so they can answer "is anyone using this?" on their own, anytime. Driving the query from the full workbook list also means unviewed content shows up right alongside everything else, instead of needing a second query to catch what never got seen.

Things to know before you use this

hist_workbooks.id is just the internal ID for that snapshot row, not the workbook itself. If you need a stable way to track a specific workbook over time, use hist_workbooks.workbook_id instead. This matters more than it sounds like it should: workbook names and even publishing locations can change during development — especially before a workbook lands in its final, published-to-prod state — so tracking by internal snapshot ID or by name alone can silently split what should be one workbook's history into several.
friendly_name availability can vary. It's present on hist_users in this table, but in other parts of the repository it only lives on system_users — worth confirming which table has it populated in your version before you build on top of this.
Self-views aren't excluded here on purpose. As written, this counts a publisher viewing their own workbook the same as anyone else. Depending on your use case that might be exactly what you want (e.g., an admin dashboard), or it might inflate "most viewed" rankings if you're handing this to creators. If you want to exclude them, add a join to the workbook's owner and filter hist_actor_user_id != owner_id.

DEV Community: Jung Kim

The Easiest Way to Snapshot Tableau's PostgreSQL Repository Over Time

The pattern

The use case

Things to know before you use this

Tracking Tableau Viewership with PostgreSQL

Tracking Tableau Viewership with PostgreSQL

The SQL

The use case

Things to know before you use this