Deep Dive into Tableau PostgreSQL Repository

Using the PostgreSQL Repository (On-Prem)

Because I run an on-prem server, I can directly query the Tableau PostgreSQL repository (“workgroup” database). If you have Tableau Cloud, you may only connect to some pre-aggregated published data sources and use the “Admin Insights” set of dashboards. So speaking about PostgreSQL Repository access to the database requires a TSM command to enable a readonly user to connect via any standard PostgreSQL clients.

What is the value in the Repository?

The PostgreSQL repository unlocks capabilities far beyond Tableau’s default admin views in the “Server/Site Status” section and gives an opportunity to build complex data models customized for your specific business case. Here’s how it transformed our BI operations:

• Deeper auditing: we started to track granular user activity, like who accessed sensitive workbooks, analyze historical logs (e.g. to find who has created or removed a specific user) and built dashboards to easily work with this data, or track usage metrics (e.g. what workbooks are not popular at all despite a high priority in their development).
• Permissions: I built a “permissions matrix” by joining and unioning multiple tables. This approach allows all BI or Data Department employees to easily find all rights permitted for any user or user group. In a second iteration, we extended access to Business Units’ managers, enabling them to view only the users relevant to their departments. This way, they could track permissions for their own dashboards and monitor employees within their teams.
• Data Hygiene: we use data from the repository to identify inactive users, duplicate accounts that clutter up the server and waste licenses.

Sample SQL Queries

Building a Permissions Matrix

One of my biggest wins was constructing a table to see exactly which user or group had “Read,” “Write,” or “Delete” on each workbook. To build this “permissions matrix,” I combined data from several key tables (primarily next_gen_permissions, workbooks, users, groups, projects, sites, etc.).

The query joins permissions data with workbooks, projects, users, and groups tables. This allows me to clearly see:

• Who (user or group) has permissions.
• What exact permissions they have (read, write, export).
• Where these permissions apply (specific workbook, project and in which site).

Here’s a simplified version of the query I use:

I then visualized it in a custom admin dashboard: columns for each workbook, rows for each user/group, with shapes or color coding for read/write. This matrix helps us to check current situation or helps business leads to see or request changes if employees no longer need certain privileges.

Checking Duplicate Emails

Due to imperfect internal processes, we sometimes ended up with users having multiple accounts under different logins. This was particularly common when employees changed departments. So we were able to find out this issue by searching for duplicate email addresses. To identify these cases, we ran the following SQL query:

This simple yet effective query allowed us to highlight all repeated emails and deactivate excessive ones.

Identifying Underused Dashboards

One of the most valuable insights I extracted from the repository was finding previously popular dashboards that users had stopped using. This early warning system alerted us to potential problems, allowing us to proactively reach out to stakeholders and understand what wasn’t suitable for them and improve our product with new iterations.

Here’s the query I used to spot dashboards with significant usage decline:

This query identifies any dashboard where usage has dropped by 30% or more compared to the previous month. When we investigated these declining dashboards by directly talking with business teams, we discovered several interesting issues they didn’t report:

• Performance issues: our dashboard became too slow after Data Engineers updated some logic in the data sources without our awareness, but users hadn’t complained — they just stopped using it.
• Shadow BI tools: some departments started using Excel or even free BI tools as a self-service instead of our centralized Tableau because they needed specific calculations — something they never mentioned to the BI developers.
• Training gaps: newcomers simply didn’t use some dashboards because of onboarding issues on the business side — and our investigation even helped to identify operational gaps in the company’s workflow.

These examples just show value in our specific cases and what’s possible with PostgreSQL repository access in general.

Your specific implementation will vary greatly depending on your organization’s context — business size, user base, centralized vs decentralized development model, self-service adoption, and permission management approach — all shape how you might leverage this data.

Rather than guessing how dashboards are used, repository data gives you an opportunity to deeply investigate what exactly is happening.