Can eBPF Provide Real-Time PostgreSQL Insights Without Degrading Performance?

Database engineers know very well how important it is to observe and monitor databases.

And it’s not just about tracking resource usage or catching failures—it’s about optimizing performance, detecting malicious queries, and keeping costs under control.

But one often not only needs highly granular information to fully understand what’s happening under the hood, but also must ensure that the added observability code does not significantly impact the database’s performance.

While there are many database solutions out there, we’re going to look at how to observe PostgreSQL using eBPF.

Can eBPF provide a low-overhead, high-visibility solution?

What impact does it have on database performance?

Is it even practical for real-world deployments?

Let’s find out.

Among the many message formats in PostgreSQL for executing SQL commands, the two we will primarily be concerned with are:

• Simple Query: Executes a single SQL command sent as a single string using the Q message type, providing straightforward and direct execution of queries like SELECT * FROM users.
• Extended Query: Uses a multi-step process involving Parse, Bind, Execute, and other message types to support complex interactions, including parameterized queries and prepared statements.

It’s not necessary for you to learn these formats, but we need to know about them to be able to parse the protocol in the eBPF program.

When a PostgreSQL client tries to write data to the database, the programming library internally triggers the write syscall to send data over the socket.

The receiving end of the socket then internally triggers the read syscall to receive data from the remote peer.

Therefore, the objective is to attach our eBPF programs to these syscall hook points:

• tracepoint/syscalls/sys_enter_write: Hooks onto a write syscall and is used to capture sent data. Provides access to the input arguments of the write syscall.
• tracepoint/syscalls/sys_enter_read: Hooks onto the entry of the read syscall and is used to capture received data, providing access to the input arguments of the read syscall.
• tracepoint/syscalls/sys_exit_read: Hooks onto the exit of the read syscall, providing access to the return values of the read syscall.

These hook points provide us access to the connection file descriptor, socket address, and PostgreSQL query data, including their type and parameters.

While it’s not directly necessary to utilize all three hook points, we can capture PostgreSQL protocol data on both the client and server sides.

Which hooks you use depends on whether you are trying to observe the database client or the database instance.

Using this we can write an eBPF Program...

Read the full post on my Substack Newsletter: https://ebpfchirp.substack.com/p/can-ebpf-provide-real-time-postgresql