Neon’s audit logging feature lets you record every single database operation happening on your Neon project.
Here’s a quick look at how it works with a sample psql session:
# Connect to your Neon database
psql postgresql://alex:your_password@ep-example-cluster.cloud.neon.tech/dev?sslmode=require
# Create a table
CREATE TABLE users (id SERIAL PRIMARY KEY, name VARCHAR(100));
# Insert some data
INSERT INTO users (name) VALUES ('Alice'), ('Bob');
# Query the data
SELECT * FROM users;
# Drop the table
DROP TABLE users;
Behind the scenes, Neon is capturing these commands, who ran them, when, and from where. This forms a comprehensive trail of your database activity.
The core problem audit logging solves is providing an irrefutable record of who did what to your data and when. This is critical for security, compliance, and debugging. Without it, tracing the origin of a data leak, understanding the cause of a data corruption, or satisfying regulatory requirements becomes a near-impossible task.
Internally, Neon’s audit logging works by intercepting all incoming SQL commands at the proxy layer before they reach the actual PostgreSQL compute instance. Each command is then enriched with metadata like the user, IP address, timestamp, and the specific Neon branch it was executed against. This enriched log entry is then asynchronously written to a dedicated, immutable log store. This separation ensures that even if the compute instance experiences issues, the audit logs remain intact.
The primary lever you control is the level of logging. You can choose to log all statements, only failed statements, or a subset of statements based on your needs. This is configured directly within the Neon console under your project’s "Observability" or "Security" settings, often presented as a dropdown or radio button selection.
The most surprising truth about audit logging is that its primary value isn’t just in detecting malicious activity, but in deterring it. The knowledge that every action is logged, and that this log is immutable and accessible, fundamentally changes user behavior. Developers and administrators become more cautious, double-checking their commands before execution, knowing that any mistake or unauthorized action will be permanently recorded. This proactive behavioral shift is often more impactful than the reactive analysis of logs after an incident.
The one thing most people don’t know is how granularly you can filter and search these logs in practice. While the system captures everything, the true power comes from being able to quickly pinpoint specific events. For instance, you can search for all DELETE statements executed by a particular user on a specific table within a given time frame, or identify all failed INSERT statements that occurred during a period of high traffic. This is typically done through the Neon console’s logging interface or by exporting the logs to a dedicated log analysis tool where advanced querying capabilities are available.
The next step after setting up audit logging is often exploring how to integrate these logs with your existing Security Information and Event Management (SIEM) systems.