DEV Community: Alex Serban

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

Alex Serban — Mon, 25 May 2026 05:49:00 +0000

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.

If someone asked you who accessed your production database last Tuesday, could you answer?

Alex Serban — Tue, 19 May 2026 06:35:45 +0000

Two scenarios.

Your biggest prospect sends over a security questionnaire.
Question 47: "Can you provide per-user audit trails for all production database access?" Or a customer emails saying they think their account may have been accessed by someone who shouldn't have had access. You have 24 hours to respond.

Both questions come down to the same thing: who ran what query, and when?

Most teams can't answer that. Not because they have no logs because their logs don't answer that question.

In March 2026, Italy's data protection authority fined Intesa Sanpaolo €31.8M. Not a breach, not data sold one employee ran 6,637 queries across 3,573 customer records over two years, no access controls stopped them, and no anomaly detection fired. Query logs existed. Per-user attribution didn't. When the regulator asked who ran those queries, the bank couldn't say.

The shared credentials problem

Most engineering teams handle production database access the same way. One readonly role. Credentials in a 1Password vault or a .env.production in secrets manager. Shared across everyone who needs it.

It works until it doesn't. A few situations where it bites:

An enterprise prospect asks for SOC 2 evidence. CC6.1 and CC7.2 require logical access controls and monitoring of system activity. Your answer: "We use a shared readonly role with pg_audit logging." Their security team: "We need per-user attribution, not role-level attribution." Deal paused.

A regulator or customer's lawyer asks about a specific record. "Show me every access to this customer's account in March." Your pg_audit logs show readonly_user ran a SELECT on the users table. You have 15 engineers sharing that role. You cannot answer the question.

An engineer leaves under bad terms. You rotate the shared credential or you don't, because rotating means hunting down every CI pipeline, every .env, every tunnel they might have set up. And even if you do rotate it, you still have no idea what they accessed in their last two weeks. The logs show readonly_user and nothing else.

What pg_audit actually gives you

pg_audit is a solid extension. You should have it. Here's a typical log entry:

2026-03-15 14:23:11 UTC [12847]: LOG:  AUDIT: SESSION,42,1,READ,SELECT,TABLE,
app.users,"SELECT id, email, created_at FROM users WHERE id = $1",<not logged>

You get the role, the statement type, the object accessed, the full query text, and the timestamp.

What you don't get: which human ran this, whether they were authorized to access that table, or which fields came back.

If every engineer has their own PostgreSQL role, pg_audit gives you genuine per-user attribution. If they share a role, you get role-level attribution. You can prove readonly_user ran a query. You can't prove it was Alex from the backend team, or that Alex's access was authorized at that time.

pg_audit is necessary. On a shared role, it's not sufficient.

What Teleport and Boundary give you

Teleport and Boundary solve the attribution problem at the session level. Each engineer authenticates with their own identity, that identity gets attached to the database session, the session is recorded. A real step up from shared credentials.

The limits are worth understanding. Both are perimeter-based they secure the path through the approved tunnel. If a credential exists anywhere else (a CI variable with a hardcoded connection string, a developer's local .env from before Teleport was rolled out, an old bastion rule someone forgot to clean up) that path is wide open.

Session recordings also create volume. To answer "which queries touched this customer record in March," you're either replaying recordings or building a search layer on top. For a regulator audit or a subject access request, being able to query logs directly beats replaying session recordings one by one, that's a real problem.

Both tools are worth having. They don't close the field-level problem.

The field-level gap nobody talks about

An engineer debugging a billing issue runs:

SELECT * FROM customers WHERE id = $1

That returns customer_id, created_at, plan_tier and also iban, date_of_birth, ssn. The engineer needed the first three. They got all six. The billing bug didn't require those fields. Returning them is a data minimization risk under GDPR Art. 5(1)(c), whether or not the access was logged.

PostgreSQL column-level privileges exist but break down with CTEs, subqueries, and joins in ways that are easy to misconfigure. The bigger issue is that most teams have never applied field-level controls to internal database access at all. They applied data minimization to their external APIs and assumed internal access was different.

The regulation doesn't make that distinction.

An architecture that closes all three gaps

The fix that actually works: engineers don't connect directly to production. This sounds annoying until you see what it enables.

Instead, they call named, typed query functions. get_order_by_id(order_id). search_customers(email_prefix). Those functions run in a policy evaluation layer between the engineer and the database. Before the query reaches Postgres, it attaches user identity from the auth context, evaluates field-level policies (does this user's role permit access to iban fields here? if not, mask or reject), and writes to an append-only audit table.

INSERT INTO audit_log (
  user_id, user_email, function_name, parameters,
  rows_returned, field_policies_applied, called_at
) VALUES (
  'usr_abc123', 'alex@company.com', 'get_order_by_id',
  '{"order_id": "ord_xyz789"}', 14,
  '{"iban": "masked", "ssn": "masked"}',
  '2026-03-15T14:23:11Z'
);

The audit table is INSERT-only. No UPDATE, no DELETE. When Alex leaves, you revoke their identity in one place. No credential rotation across 12 pipelines.

How the options compare:

Control	Per-user attribution	Field-level control	Revocable on offboarding	Immutable log
Shared DB role	No	No	No	No
pg_audit (shared role)	No	No	No	Yes
Teleport / Boundary	Yes	No	Partial	Yes
Application-layer proxy	Yes	Yes	Yes	Yes

You can build this yourself. The pieces exist in the Postgres ecosystem. Whether it's worth the build time and maintenance is a separate question.

This is what Scalple implements, free for teams under 15 users. Either waycan you answer "who accessed that record and when" before someone asks?