It’s been a couple weeks since P2D2 (Prague PostgreSQL Developer Day) 2025. We’ve been busy with the various tiny tasks that need to happen after the conference - processing feedback, paying invoices, and so on. But it’s also a good opportunity to look back - I realized this was the 15th year of the event I’ve helped to organize, so let me share some of that experience.

This is going to be very subjective. This is how I remember it, what I think was important, and how I envision the future of this particular event to look like. I don’t pretend to speak for other organizers.

I also don’t claim our experience is somehow universal. I’m sure there are other ways to organize similar events, be it intentional or forced by circumstances. You may want to shape the event differently, for different audience. Or maybe you can’t use a university venue, and have to go with a commercial venue. I’m sure the Prague conference might have looked very differently.

If you’re interested in a more official review of the 2025 event, maybe take a look at the official feedback summary published by the org team a couple days ago. It presents summary of feedback on the conference and talks, and responds to various comments. There’s also a nice blog post by Ants Aasma, one of the speakers, sharing his experience from the conference. There are also photos from this year, or from previous years.

Location, location, location!

The first P2D2 conference happened in 2008, i.e. same year as the PGDay Europe, which eventually transformed into pgconf.eu. I was not involved in organizing at that point, the local PUG doesn’t exist yet either. It was all thanks to Marek Kocan, Zdenek Kotala and a couple other people. Without these first years, there’d be no P2D2.

The first two years happened at FEL (Faculty of Electrotechnics). I stumbled upon a recording of one talk from the very first year. The photo above is from 2009. Then in 2010 the event moved to Masaryk Dormitory (same university, but in a different part of the city).

In 2011 the event moved again, this time to Department of Software Engineering at Charles University, where it stayed until 2014. In 2015 we moved to Faculty of Informatics at ČVUT, a brand new building in Dejvice. We’ve been there for 10 years already (wow!), and so far it works pretty great for us.

Until 2014, the conference was a one-day event with a single track of talks. In 2015 we extended it to two days, with workshops on the first day. And then in 2025 (i.e. this year) we expanded to two tracks. We don’t have any clear plans what to change next, but we’re more likely to add another track before expanding to more days. And it may take a while before we get to do that.

Size of the event

As for the number of attendees, I don’t think we have reliable numbers for the first couple years, because there was no formal registration or payment. From the 2008 recording I’d guess there were ~50 people, I’m sure there were more people in 2010 (maybe 100?).

Here’s a chart for the number of attendees between 2012 and 2025, from our registration system. There is certain amount of inaccuracy, due to how we handled registration for speakers and tickets granted to students etc.

Between 2011-2014 the event grew to ~100 attendees. which I know because that was the capacity of the room at Charles University, and we started to run out of spaces. The only solution was to find a new venue. A couple PUG members suggested the new FIT building, so we tried that, and it turned out to be a great venue. It can fit many more people, with the largest room having ~280 seats.

For a while that was fine, but in 2019 we started to hit ~250 attendees, and it was clear we’re about to start running of space again. I’m sure we could have got 300+ this year, considering the size of the wait list. We’re not going to move to another venue, though. It would be hard to find an affordable venue with higher capacity, but more importantly we don’t really need / want a one big room for a single track of talks.

This year we’ve decided to switch to two tracks, to allow more talks on a wider range of talks. And that can be done at the current venue just fine, and it means we can increase the capacity.

Hallway track

After we switched to two tracks, we kept the same number of talks per track. I think we’ll need to adjust this next year, because this left only very short breaks between talks (only ~5 minutes). That is just enough to change the room, but it requires adhering to the schedule very tightly. If a talk in one track gets just a little bit longer, that might derail the schedule.

Making the breaks longer would also help with the “hallway track”, an underappreciated part of a conference. The talks are very important, of course, and I enjoy them. But I realized it’s not the main reason why I’m attending in-person conferences. If that was the case, I could simply watch the talk on youtube instead. It’s about the opportunity to chat with other attendees between talks, either about the talk, a related topic, or even something random.

This is known as a “hallway track”, a conference version of “watercooler chat”, and it’s even more important in the world of remote-first work. It requires a bit of slack in the schedule, and the 5-minute breaks are just not enough if you also need to move to a different room etc.

If we make the breaks a bit longer (say 10 minutes), that solves both issues. It makes it easier to follow the schedule and keep the rooms in sync, and it gives more space for the hallway track. It’s a win-win.

Humble low-cost event

The conference started as a very humble low-cost event, and we intend to keep it like that. For the first couple years it was free, and the ticket price we’re asking now is still very affordable.

This was both a conscious, intentional choice, and a necessity. Our goal was to organize a community event for developers, accessible to everyone (especially for students). Such events are not a great match for traditional marketing, focused on talking to customers and collecting leads. And so we don’t want to rely on sponsors too much.

(Don’t get me wrong. We’re absolutely grateful to every single sponsor who supported us, and we try to make the event work for sponsors. But we’re not going to abandon the vision of a community developer event.)

For the first couple years the event was virtually free, but there was no substantial catering or similar stuff. Over time we gained a couple sponsors, usually from companies using Postgres. And we started to ask for a modest registration fee - initially €10 for the whole day, currently it’s about ~€50.

This allowed us to start providing proper catering - lunch, coffee breaks, recently even a small reception with drinks at the end. Which is a huge benefit, as it allows the people to stay at the event the whole day, socialize during lunch, etc.

But we still keep the event very low key, and we intend to keep it that way. The higher the expenses, the higher the necessary income (either from attendees or from sponsors). And the higher the risk of losing money, affecting the budget of the PUG organizing the conference.

Conference budget

To give you a very rough idea, the budget of the P2D2 2025 looks about like this:

• +12,500 EUR tickets
• +7,500 EUR sponsors
• -15,000 EUR catering
• -4,000 EUR mugs, t-shirts, …
• -2,000 EUR other expenses (speaker dinner, gifts, badges, …)

Those are the main items on the budget. Catering is clearly the main expense, and most of the money comes from tickets and sponsors. Overall it’s reasonably balanced, but we’re not making any “cushion” for the future.

With ~270 attendees, this means we get ~45 EUR / attendee by selling tickets (a ticket is ~50 EUR, but we also give some free tickets for sponsors, students, speakers, etc.).

The “expenses” are ~70 EUR / attendee, and it’s hard to cut this - most of this is catering, and we really want to have that for convenience. Otherwise the attendees would have to find a place on their own, risking missing some of the talks, etc.

This gap between per-attendee expenses and income is not great. We cover the difference (about ~25 EUR) using the income from sponsors, but somewhere around 270 people we break even. Every additional attendee means a small loss, pushing us into red numbers.

That’s not great, and we need to improve this in the future. We can either increase the ticket price a bit, find some new sponsors, or make the sponsorships a bit more expensive. I assume we will do a bit of each, to keep the event accessible (both for people and for sponsors).

Budget and timing challenges

One non-obvious challenge is with the timing. In an ideal world, we’d open “call for sponsors”, wait until we know how much money we get from sponsors. And then we’d set the ticket price to cover the rest with a bit of margin. If we get extra sponsors later, that’d be money we can keep for next year.

Unfortunately, that doesn’t quite work in practice. We can’t set the conference dates until the university finalizes the schedule for the year (we need to fit into exams period not to overlap with regular lectures, etc.). Which does not happen until early October, which does not leave much time to sort out the sponsorships.

(Not to mention end of year is not a great time to ask for sponsorships, because the sponsorship budget is usually fully allocated.)

So we’ve been forced to set the ticket price and open registration earlier, while still talking to potential sponsors. To keep the event affordable, we have to predict how many sponsors will join, based on experience from previous years etc. In most cases it worked in the end, but there’s a risk we’ll be too optimistic.

We’re getting better at setting the dates early, and we can probably start with tentative dates. After all, the window for the conference is fairly narrow, because the university schedule does not change very much. It might be two or three weeks (end of January / early February), but that might be enough at the early stage. Especially for sponsors without on-site booths.

But even then it may take time to get the sponsorships approvals through. That’s yet another reason to build up some cushion and be less reliant on this income.

It might be a bigger problem for call for papers (CfP), though. Giving a talk requires on-site presence, and without the exact date set you may not know if you can make it. Not sure what to do about this, except for making sure to set the date before the CfP ends.

Talk proposals

The last paragraph reminded me how the CfP changed over the years, and the challenges with that part of the organization. When we started with the conference, we aimed to have most talks in Czech. The goal was to organize a local community event, and some of the attendees did not know english well enough. I recall we used to have two talks in English, and then one year we happened to have three, and got multiple complaints in the feedback.

Unfortunately, the pool of local speakers is rather limited, and we did not want to have the same speakers every year. It turned out quite challenging to get enough good talk proposals. We definitely would not be able to do two tracks with only Czech talks, for example.

In the past couple years we switched to most talks being in English, mostly due to the difficulties with getting enough proposals in Czech. And this time we didn’t get any major pushback. I guess the audience changed quite a bit. Many either learned English well enough, or already come from an environment where English is the default.

The pool of speakers for talks in English is much larger. We also intentionally schedule the event right next to FOSDEM, to make it easier for people going to FOSDEM to also submit a talk for Prague. That worked pretty well, and we plan to stick to this.

This also made the conference accessible for foreigners who came to work in IT (be it in Prague, Brno or elsewhere in Czech). We didn’t quite appreciate how large this group grew, and it’s understandable as we were running a conference with most talks in Czech.

So doing more talks in English turned out to be a a win-win. We get more talk proposals, and we also made the conference much more accessible to a large group of people.

This does not mean everything is “rainbows and unicorns”, of course. It takes time and effort to promote the conference to get the proposals, and we’re extremely grateful to everyone who submitted proposals. We hope to do at least this well next year.

The organization team

While I may be the most visible organizer of the Prague conference, especially in the early years, I definitely could not run this alone. Luckily I don’t have to, because there’s a small group of people handling a significant part of the work - both before, during and after the event.

I’m sure I’ll forget someone, but recently it’s mostly these people:

• Pavel Stěhule
• Aleš Zelený
• Pavel Hák
• Jan Pěček
• Matěj Klonfar
• Gülçin Yıldırım Jelínek

We also get valuable help from a couple people at the university, like Michal Valenta, Adéla Svítková and Jan Matoušek.

I don’t have any ground breaking recommendations on how to organize the team. It’s a pretty standard case of team management, even if the team is rather informal and flat.

Of course, there’s a couple things I’d do differently. In particular, I’d delegate stuff earlier, even if it may not be strictly necessary and may even means lower efficiency at that instant. Yes, I may need to explain the task to someone, which takes more time that doing it myself. But it has a bunch of massive benefits in the long run:

• It adds resiliency/redundancy, as I’m not the only person knowing how to do that or that it was done at all.

• It allows other team members to feel engaged, especially if it’s delegated as a goal (i.e. if it’s up to them to decide how to get it done) and not as a task.

• Ultimately it greatly reduces the pressure on individual organizers. If the responsibility is shared, so is the pressure.

As I said, none of this is some magical management advice …

After each conference we collect and evaluate feedback, trying to learn something for next year. Not just feedback from attendees/sponsors, but also internally from every member of the organization team. This internal feedback is very valuable to decide what worked and what did not, what to change next year. It was the main driver for a couple major changes in recent years, all of which turned out to be positive. Switching to multiple tracks of talks or using QR codes to speed up registrations are good examples.

PostgreSQL Event Services?

When organizing a local PostgreSQL event, you’ll need to figure out how to handle a bunch of conference stuff:

• registrations
• talk proposals
• sponsors
• payments
• feedback
• …

For the Prague conference, we started with nothing - initially there were no registrations, no sponsors, …. And then over the years we gradually developed a combination of existing and custom tools. For example the CfP is still using Google Forms, while the registrations are handled through a custom Python webapp.

If we had to implement all of this on day one, that’d be quite hard, even if it’s not particularly complex. The webapp has a couple pages, and it’s not much more than a CRUD app, collecting info from the attendees, handling payments, sending e-mails. I think I’d be able to write it from scratch in a couple days. But the hard part is knowing what it should do.

There are definitely things we’ll need to improve. For example, we still rely on Google Forms for the CfP, and the processing (rating/accepting/rejecting talks, sending notification) is largely manual. That worked well for modest numbers of proposals and a single-track event, but this year we switched to two tracks and got a lot more talk proposals. And that made the manual process very demanding.

Not just by having to do more work, but also keeping track of everything. It was stressful to make sure we accepted the right number of talks, rejected the rest, tracking who confirmed the talk, and so on. The manual process definitely does not scale beyond a single track, we will need to rethink and automate that in some way. Perhaps by integrate that into our webapp.

The thing is - if you’re starting a new event, chances are it’ll start small too. Which means the off-the-shelf solutions like Google Forms may work well enough. And you will develop something better over time.

But there may be another option now. If you’re organizing a community event, the PostgreSQL Europe offers Event Services, which handle most of these tasks for you using the same interface / web application developed for PostgreSQL Conference Europe.

Another benefit is that you don’t need a local entity to run the event, because all the contracts (with the venue, catering, …) will be signed by PGEU.

You’ll still need to do all the other tasks, of course. You’ll need to find the venue, pick dates, prepare budget, promote the event, … That’s not something PGEU can do for you.

We didn’t use the event services for Prague, because when we started the offering did not exist. And we don’t expect to use that in the future, because we already have a local entity and everything else figured out. We may consider adopting the web application, but that can be done even without the event services.

If I was starting a new event, I’d seriously consider using it. I did hear about two events who tried using it in 2024 and ran into some issues. I believe this was a consequence of the offering being very new and insufficient initial guidance. I hope it gets resolved and it gets smoother for future events.

If you choose to do something custom, my recommendation is to not over engineer stuff. Minimal and “dirty” solutions were good enough for us for a long time. At some point you’ll need something better, but that’s a problem for a future you.

There’s also cost of operating a more complex solution, and it may not be worth it for a small event.

Conclusion

I’m quite happy with how the Prague conference works and feels, and with the direction, and I hope it’ll continue as a community developer event.

We need to figure out how to deal with the budget challenges. We wont be able to set the dates much earlier, which means we’ll always have trouble with signing sponsors before having to open registration. My guess is we’ll need to increase the ticket price a little bit, to compensate for the risk of getting fewer sponsors. But we’ll always aim to keep it as affordable as possible.

One thing I didn’t mention is talk recordings. We happened to realize we can record them through the venue AV system with no additional cost, and the quality seems to be pretty good. We plan to publish them over the next month or so, and we expect to record talks in the future. (Of course, it’s not required, and a speaker can decline at any time.)