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 most common production configuration 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:
Data subject access requests. Under Article 15, a data subject can ask for a complete record of who accessed their personal data and when. If your audit log only shows app_user, you cannot produce a complete response. An incomplete DSAR response is itself a violation.
Insider access investigations. Both France Travail and Intesa Sanpaolo involved authorized users accessing records outside their legitimate scope. In both cases, the regulator found the company could not reconstruct what happened which is treated as evidence of inadequate controls, regardless of intent.
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.
Per-user database roles solve the attribution problem cleanly each person connects with their own credential, and pgAudit attributes correctly. In practice, this is incompatible with connection pooling at any meaningful scale, requires role management across every migration, and breaks most ORM configurations.
Application-level audit middleware covers queries that go through your application. It misses direct database access by engineers running ad-hoc queries, analytics tools, migration scripts, and DBA sessions exactly the access paths that created liability in France Travail and Intesa Sanpaolo. If your application logs are your only audit trail, those paths are invisible.
A query proxy sits between your application and your database, intercepting before the connection pool strips identity. It covers every access path application queries, direct connections, analytics tools, and DBA sessions all pass through the same point. It requires no changes to your application code, your ORM, or your database role structure.
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.
The demo at scalple.com runs against a live PgBouncer connection pool. You can see exactly what your current pgAudit log is missing and what a compliant per-user audit log looks like in its place.
Scalple is a database audit platform for B2B SaaS teams with GDPR obligations. Per-user query attribution at the proxy layer, no application code changes required.
