Tomas Vondra

If I could give one piece of advice to the past me, starting to contribute to open source projects, it’d be to value other developers' time more.

Every now and then I need a break from writing code.

A couple months back I posted about maybe adjusting random_page_cost to better reflect how current storage handles random and sequential access.

At a couple recent conferences, I got to describe the process Postgres uses to select new committers/maintainers.

The random_page_cost was introduced ~25 years ago, and since the very beginning it’s set to 4.0 by default.

If you attended FOSDEM 2026, you probably noticed discussions on how AI impacts FOSS, mostly in detrimental ways.

I do a fair amount of benchmarks as part of development, both on my own patches and while reviewing patches by others.

A couple weeks ago I posted about how setting maintenance_work_mem too high may make things slower.

I’ve been using Qubes OS as my primary OS since version 2, released in 2014.

I work remotely from home, and over the years I’ve amassed a bunch of machines related to that (development, testing, benchmarking, …), and other devices you may usually find at home (printer, NAS, …).

From time to time I get to investigate issues with some sort of a batch process.

PostgreSQL 18 was stamped earlier this week, and as usual there’s a lot of improvements.

Row-level security (RLS) is a great feature.

When I started working with Postgres (or databases in general) 25 years ago, storage systems looked very different.

Last week I posted about how we often don’t pick the optimal plan.

The basic promise of a query optimizer is that it picks the “optimal” query plan.

I do a fair number of benchmarks, not only to validate patches, but also to find interesting (suspicious) stuff to improve.

The pgconf.dev conference, a revamp of the original PGCon, happened about two weeks ago.

We’re now in the “feature freeze” phase of Postgres 18 development.

Last week I visited the Malmö PUG to talk about performance cliffs.

It’s been a couple weeks since P2D2 (Prague PostgreSQL Developer Day) 2025.

A couple days ago I wrote about performance improvements on OLTP workloads since Postgres 8.0, released 20 years ago.

The Postgres open source project is nearly 30 years old, I personally started using it about 20 years ago.

If you’ve done any Postgres development in C, you’re probably aware of the concept of memory contexts.

There are multiple tools to run benchmarks on Postgres, but pgbench is probably the most widely used one.

A couple days ago I had a bit of free time in the evening, and I was bored, so I decided to play with BOLT a little bit.

Time for yet another “first patch” idea post ;-) This time it’s about BRIN indexes.

I’ve submitted a lot of talk proposals to a lot of Postgres conferences over the years.

Let me present another “first patch” idea, related to a runtime stats on access to files storing data.

I’ve decided to experiment a little bit and do regular “office hours.”

In an earlier post I mentioned I plan to share a couple patch ideas, suitable for new contributors.

A couple weeks ago I needed to move my mailing list communication to a different mailbox.

Picking the topic for your first patch in any project is hard, and Postgres is no exception.

Postgres is pretty old.

About a month ago I presented a keynote at Swiss PGDay 2024 about the state of the Postgres community.