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:

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?