The pgAudit Attribution Gap: Why Role-Level Logging Fails GDPR and How to Close It

pgAudit tells you what your database did. GDPR requires you to prove who did it. Those are different questions, and most PostgreSQL setups can only answer the first one.

What pgAudit Actually Logs

pgAudit is a PostgreSQL extension that captures query-level events at the database session layer. A typical entry looks like this:

2026-03-14 11:22:08 UTC [8841]: [4-1]
  user=app_user,db=production,app=psql
  AUDIT: SESSION,1,1,READ,SELECT,TABLE,users,
  SELECT id, email, subscription_tier FROM users WHERE region = 'EU';

This tells you: the role app_user ran a SELECT against the users table at 11:22 UTC. Accurate. Tamper-resistant. Exactly what pgAudit is designed to produce.

It does not tell you which human being was behind that session.

In every production PostgreSQL application using a connection pooler — PgBouncer, PgCat, Odyssey — all queries arrive at the database authenticated as a shared service account. Your Django backend, your Node API, your internal admin panel, and your data team’s analytics queries all hit Postgres as app_user. pgAudit logs all of them identically.

The Gap, In Two Log Entries

This is the difference between a compliant and a non-compliant audit trail:

What pgAudit produces (shared credential)

2026-03-14 11:22:08 UTC
  user=app_user
  SELECT id, email, subscription_tier FROM users WHERE region = 'EU'
  rows_returned: 47291

What a compliant audit log contains

2026-03-14 11:22:08 UTC
  session_user_id: employee_id_2291
  session_email: j.muller@company.com
  db_role: app_user
  query: SELECT id, email, subscription_tier FROM users WHERE region = 'EU'
  affected_table: users
  columns_accessed: id, email, subscription_tier
  rows_returned: 47291
  masked_fields: email → j***@***.com
  log_id: immutable-7a3c91f2

Same query. Same shared credential. Same database. The difference is where the user’s identity was captured.

Run this on your database now: SELECT usename FROM pg_stat_activity;

If every row shows app_user instead of individual emails, you have the gap.

Why the Obvious Workaround Doesn’t Hold

The standard response to this problem is session-level injection: set a PostgreSQL session variable that identifies the current user before each query.

SET app.current_user = 'alice@company.com';
SELECT id, email FROM users WHERE id = $1;

pgAudit then captures alice@company.com. The attribution problem appears solved.

It is not solved in most production systems.

The reason is PgBouncer in transaction mode — the default configuration for production deployments because it provides the best connection multiplexing efficiency. In transaction mode, a client connection is bound to a server connection only for the duration of a single transaction. Between transactions, the server connection is returned to the pool and reassigned to a different client.

When that reassignment happens, session state resets. The SET app.current_user variable you injected at the start of your request is gone before the next query runs. You get no error, no warning, and no log entry indicating the attribution failed. The audit log quietly fills with app_user entries while your system appears to be working correctly.

This is not a configuration mistake you can fix. It is how transaction-mode pooling works.

What GDPR Actually Requires

In January 2026, CNIL fined France Travail €5 million. The decision cited two specific Article 32 failures: access authorizations defined too broadly, and logging insufficient to detect abnormal behaviour. The investigators could not reconstruct the full scope of the breach because the logs did not capture enough granularity.

In March 2026, Italy’s Garante fined Intesa Sanpaolo €31.8 million. One employee ran 6,637 unauthorized queries across 3,573 customer records over 460 working days. pgAudit ran throughout. Not one query triggered an alert, because pgAudit attributed every query to app_user— making the employee’s pattern invisible.

Neither company lacked logging. Both lacked attribution.

Article 5(2) of GDPR requires you to demonstrate that personal data is processed lawfully. Article 32 requires appropriate technical measures. The operational implication, made explicit by both decisions: your logging must be sufficient to identify which person accessed which records, not just which role executed which query.

Two scenarios where this becomes an immediate liability:

The Fix: A Query Proxy Covers Every Access Path

There is only one approach that covers all paths into your database: a query proxy layer that intercepts every query before it reaches Postgres, while the application-layer identity is still available.

How Scalple Closes the Gap

Scalple is a query-level PostgreSQL proxy. It runs between your application and your database and intercepts every query before it reaches Postgres.

Here is how identity capture works: your application passes the authenticated user’s identity as a connection parameter — a single line in your database connection string, not an application code change. Scalple reads this parameter at the connection layer, before PgBouncer enters the picture. Because Scalple sits in front of PgBouncer, the transaction-mode session reset that breaks SET app.current_user does not apply — identity is captured at the proxy layer, not the session layer.

For each query, Scalple writes an immutable, append-only log entry: the user ID, session metadata, the full query text, the tables and columns touched, masked values for fields you designate as PII, and a tamper-evident log ID. Then it forwards the query to Postgres as normal.

Your application continues connecting as app_user. Your PgBouncer configuration does not change. Your ORM does not change. Deployment is a connection string change — your app points to Scalple instead of directly to Postgres, and Scalple forwards to Postgres. Setup takes under 30 minutes.

If CNIL asked you today for every access to a specific user’s data over the last six months, Scalple gives you that query in under a minute. Without it, you have app_user.

Before the Next Fine

France Travail was fined €5 million. They had logging. The logging was insufficient because it could not reconstruct who accessed what.

Intesa Sanpaolo was fined €31.8 million. They had pgAudit running for 460 working days. One employee’s unauthorized access pattern was invisible the entire time.

The engineering team that enabled pgAudit and stopped is not non-compliant because they chose the wrong tool. pgAudit is the right tool for query-level database logging. It is not the right tool for GDPR access attribution, because in a pooled environment it cannot attach a human identity to a database query.

Scalple is a PostgreSQL audit proxy for B2B SaaS teams with GDPR obligations. Per-user query attribution at the proxy layer, no application code changes required. Free for teams under 15 users.