Observed Signal · May 19, 2026 · Technical Guidance · Source: DEV Community · Impact: 3/5 · Sentiment: Neutral
Can You Audit Who Accessed Your Production Database?
A developer post examines common failures in attributing human access to production databases and proposes an architecture to provide per-user, field-level, and immutable audit trails. The article cites a March 2026 Italian regulator fine of €31.8M against Intesa Sanpaolo after an employee ran 6,637 queries across 3,573 customer records over two years with no per-user attribution. It explains that pg_audit provides role-level query logs, while tools like Teleport and Boundary add session-level attribution but not field-level controls. The author recommends routing all access through named, typed query functions with a policy evaluation layer that masks fields, attaches user identity, and writes to an append-only audit table — an approach implemented by Scalple.
Highlights regulatory risk and auditability gaps in production database access that affect compliance (SOC 2, GDPR) and data governance practices for companies handling user data.
Track PostgreSQL Signals & Market Shifts in Real-Time
Polaris7 autonomous intelligence agents track regulatory filings, primary sources, executive changes, and deal flow 24/7. Create your free Explorer workspace to monitor these entities.
Key Takeaways & Evidence Grounding
- In March 2026 Italy's data protection authority fined Intesa Sanpaolo €31.8M after an employee executed 6,637 queries across 3,573 customer records over two years without effective access controls or per-user attribution.
- pg_audit (PostgreSQL extension) logs role, statement, object, query text and timestamp but does not provide which human ran a query when multiple people share a database role.
- Teleport and Boundary provide session-level attribution by attaching individual identities to database sessions and recording sessions, improving on shared-credential setups but not enforcing field-level controls.
- The proposed architecture routes engineers through named, typed query functions evaluated by a policy layer that enforces field-level access, attaches user identity, and writes to an append-only audit table.
- Scalple is cited as an implementation of the application-layer proxy approach; the author notes it is free for teams under 15 users.
Connected Companies & Entities
1 Entity mappedOntology Mapping & Concepts
Related Market Signals & Shifts
Recent verified developments and strategic activity across this market segment.
Read-only Postgres can still disrupt production
A technical blog post explains that marking a Postgres connection as read-only does not guarantee safety: exploratory joins, wide aggregates, concurrent retries, and synchronized schedules can consume shared connections, CPU, memory, I/O, and replica capacity and thus harm production. The author recommends treating AI-driven database traffic as a separate workload class with a dedicated least-privilege role, a bounded connection pool acting as an admission controller, enforced statement/lock/row/byte limits, explicit replica freshness contracts, propagated deadlines and cancellations, capped retries with jitter, and rejection or deferment when budgets are exhausted. The post warns that replicas are not free capacity and that safe overload responses must be visible and bounded. A full guide on isolating AI workloads in Postgres is linked.
Open-source ShadowAudit Stops PII Leaks to LLMs
ShadowAudit is an open-source tool that inspects prompts leaving an application to any LLM API and blocks or flags personal data before it reaches the model. It detects items such as email addresses, phone numbers, API keys, and Indian national IDs (Aadhaar and PAN), and can be integrated with two lines of code as a wrapper around existing LLM clients. ShadowAudit also produces GDPR Article 30 compliance reports automatically from its audit logs. The project is published on GitHub by the author as part of an open-source portfolio and the author requests community feedback.
Why We Abandoned PostgreSQL Row-Level Security at Scale
A technical post examines why row-level security (RLS) in PostgreSQL, while effective for small multi-tenant SaaS deployments, becomes problematic as tables grow past ~1M rows and tenant counts increase. The author describes measurable query overhead (single-digit percent on simple queries, rising with complexity), harder debugging because RLS can silently filter results, and operational fragility from relying on a session variable (e.g., app.current_tenant) that must be set on every connection — complications exacerbated by poolers like PgBouncer. The post argues that for high tenant counts and large data volumes the tradeoffs often favor structural isolation (database-per-tenant) which removes RLS overhead, debugging ambiguity, and session-variable dependencies. RLS still has valid uses for small/fixed tenant sets or as an intermediate safeguard against missing WHERE clauses.
Track Real-Time Market Signals & Shifts
Set up custom watchlists to receive automated, evidence-grounded executive digests whenever material signals or shifts occur across your tracked landscape.