DEV Community: Jung Kim

Tracking Tableau Server Storage Over Time with PostgreSQL

Jung Kim — Wed, 29 Jul 2026 11:15:31 +0000

Tableau's admin views show you storage at a single point in time, but they don't give you a trend line. If you want to know whether your server's footprint is growing, shrinking, or holding steady, you need to snapshot it yourself. Here's the query I run daily to do that.

The SQL

SELECT
    CURRENT_DATE                                        AS snapshot_date,
    ROUND(SUM(CASE WHEN content_type = 'Workbook'
        THEN size ELSE 0 END) / 1000.0^3, 2)           AS workbook_storage_gb,
    ROUND(SUM(CASE WHEN content_type = 'Datasource'
        THEN size ELSE 0 END) / 1000.0^3, 2)           AS datasource_storage_gb,
    ROUND(SUM(size) / 1000.0^3, 2)                     AS total_storage_gb
FROM (
    SELECT
        'Workbook'                                      AS content_type,
        size
    FROM _workbooks

    UNION ALL

    SELECT
        'Datasource'                                    AS content_type,
        size
    FROM (
        SELECT DISTINCT ON (id)                         -- one row per datasource, dropping duplicate connection rows
            size
        FROM _datasources
        ORDER BY id, created_at                         -- deterministic pick when duplicates exist
    ) deduped
) content

The use case

I run this once a day and store the output, turning a single point-in-time snapshot into an actual trend line — workbook storage, datasource storage, and a combined total, all in GB. Over time this becomes the backbone for answering questions like "is our cleanup effort actually reducing our footprint?" or "how fast is storage growing month over month?" — the kind of thing that's easy to ask and impossible to answer from the Tableau UI alone.

Setup is just publishing this as an extract with incremental refresh turned on, scheduled daily. I cover the mechanics of why that combination works so well — and other metrics you can track the same way — in The Easiest Way to Snapshot Tableau's PostgreSQL Repository Over Time.

Pair this with viewership tracking from my last post and you've got both sides of the story — who's using your content, and how much room it's taking up.

Things to know before you use this

_datasources overcounts without deduplication. Each data connection on a multi-connection datasource gets its own row, all carrying the same size value. Without handling this, a datasource with three connections gets counted three times. The DISTINCT ON (id) subquery above collapses that back to one row per datasource. Before trusting this in production, run a quick sanity check:

SELECT id, COUNT(*), MIN(size), MAX(size)
FROM public._datasources
GROUP BY id
HAVING COUNT(*) > 1

If MIN(size) equals MAX(size) for every duplicated id, deduplication is safe as written. If they differ, you'll need to decide which value to trust before summing.

Tableau Server uses decimal, not binary, storage units. Divide by 1000 (not 1024) at each step to convert bytes → KB → MB → GB and match what the Tableau UI itself reports.

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.