Event: PGConf.Nepal 2025
Venue: Kathmandu University, Dhulikhel, Nepal
Date: 5-6 May 2025

I presented this session at PGConf.Nepal 2025, where I had the opportunity to share the stage with leading PostgreSQL community voices and speak to an audience interested in the future of data, security, and open-source technology.

The session focused on a problem that is becoming more important as PostgreSQL powers not only traditional applications, but also analytics pipelines, internal tools, and AI workloads: securing sensitive data at the database layer.

Modern teams often secure the application front door with authentication, roles, and user interfaces. But if the database underneath remains broadly accessible, poorly audited, or loosely backed up, sensitive data can still leak through the back door.

Why this matters

PostgreSQL is often at the center of the modern data stack.

It may support customer-facing applications, internal dashboards, analytics pipelines, upstream data lakes, and AI models that rely on embeddings, predictions, or recommendation data.

That makes database security a product, governance, and engineering concern - not only an infrastructure concern.

In the talk, I explored how teams can use PostgreSQL-native capabilities to reduce the risk of exposing personally identifiable information while still supporting useful analytics and AI workloads.

Key themes from the session

Data classification should come first

Before applying controls, teams need to know what they are protecting.

High-risk fields such as national IDs or card numbers may need stronger controls such as Row-Level Security, pgcrypto, pgAudit, and encrypted backups. Medium-risk fields such as email or age may need masked views, audit reads, or scoped access. Low-risk aggregate data may only need basic role-based controls.

The point is simple: classify first, then apply the right level of control.

Row-Level Security can reduce broad data exposure

Row-Level Security helps make sure users or roles only see the rows they are allowed to access.

In the session, I used a scenario where AI training data in a user_profiles table could expose names, emails, and embedding vectors. RLS can help restrict access by user, role, tenant, or other business rules.

This is useful because the control is enforced at the database layer, not only through the application interface.

Column-level protection matters for PII

Some data should not be visible just because someone has table access.

The session covered column-level protection using approaches such as pgcrypto, column-level permissions, and access-controlled decryption. This is especially relevant when databases contain national IDs, emails, phone numbers, or other personal data used by analysts or AI pipelines.

The important principle is to avoid leaving sensitive plaintext data available where it is not needed.

Least privilege should apply to teams and pipelines

Different users need different access.

Data scientists, business analysts, backend developers, and machine learning pipelines should not all connect with broad permissions. The session covered granular roles such as analyst access, developer access, and ML pipeline access, with permissions scoped to the tables and columns each role actually needs.

For AI workloads, this is especially important. Pipelines should not run with superuser access just because they are technical systems.

Anonymize before analysis

Analytics teams often need patterns, trends, and segments. They do not always need names, emails, or real identifiers.

The talk showed how views or transformation scripts can support pseudonymization and anonymization before data is used for analysis or model training. A marketing view, for example, can expose purchase history and broad regions while hiding direct identifiers.

This is where data governance becomes practical: people get the data they need, but not more than they need.

Audit access and exports

If sensitive data is exported and later leaked, the team needs to know who accessed it, when, and from where.

The session covered pgAudit and PostgreSQL native logs as part of a traceability approach. For high-risk tables and exports, logging should not be treated as a technical afterthought. It should be part of the control design.

AI workloads need special attention

Vector search introduces new security questions.

Embeddings can still encode sensitive context. Metadata may link vectors back to real users. Similarity search can expose more than expected if query limits, access rules, and logs are weak.

The session covered safer patterns for AI workloads in PostgreSQL, including restricting vector tables through roles, views, or RLS, logging embedding queries, limiting nearest-neighbor results, and masking metadata that links vectors to user identity.

Backups and transit are part of the control story

Security cannot stop at the production table.

The session also covered TLS for protecting data in transit and encrypted backups for protecting data at rest outside production. Backups often outlive production systems, so they need encryption, key management, restore testing, and disaster-recovery drills.

A backup that cannot be safely restored or verified is not a control. It is only a hope.

What I wanted people to take away

PostgreSQL already provides many controls that can support privacy, data governance, and AI governance.

The challenge is not only knowing that these features exist. The challenge is applying them in the right places, based on data sensitivity, user roles, workload type, and risk.

For me, the bigger message was this:

Database security is no longer only about protecting tables. It is about protecting the data lifecycle behind products, analytics, and AI systems.

As more teams use PostgreSQL for AI workloads, security needs to move closer to the data itself.