FOSDEM 2026: Day One — the Open Source Spirit

This past weekend, I attended my first day of FOSDEM 2026 with a colleague. If you haven’t heard of it, FOSDEM (Free and Open Source Software Developers’ European Meeting) is one of the largest open source gatherings in the world, held every year in Brussels. It’s free to attend, which still blows my mind given how much good stuff is packed into two days.

What follows is a cleaned-up version of my hand-written notes, expanded with context from the official talk descriptions. Part personal recap, part nudge to check out FOSDEM if you haven’t.

The morning pivot: Storage aspects consumed by OpenCloud

Our day didn’t go according to plan. We wanted to catch the Main Track talks, including the opening ceremony and the first keynote on FOSS in times of war, scarcity and AI. But FOSDEM being FOSDEM, the Main Track room was already full by the time we arrived. So we pivoted to what was supposed to be our third talk.

This turned out to be a pleasant surprise: “Storage Aspects Consumed by OpenCloud” by Dr. Jörn Dreyer in the Software Defined Storage devroom.

OpenCloud deliberately avoids relying on a relational database, which means it needs deeper integration with storage systems through extended file attributes. The talk covered:

File synchronization on Software Defined Storage (SDS) — OpenCloud syncs files updated on SDS and maintains a full tree size, unlike traditional POSIX file systems.
Storage drivers — Two main ones: DecomposedFS (which the presenter described as “almost flipped upside-down POSIX”) and PosixFS. PosixFS stores files in a folder structure matching what users see in the interface, while DecomposedFS uses a more technical internal structure. PosixFS is now the default for new installations.
ID-based file lookup — Changing a file’s name or metadata must never break shared links. This is fundamental to how OpenCloud handles sharing.
NATS for metadata caching — This was the most interesting part for me. OpenCloud uses NATS (specifically NATS JetStream) as an event broker and for caching file metadata. The presenter explained that this has proven much faster than relying on POSIX syscalls. I found this particularly interesting because we use NATS at work in various capacities. I’ll need to revisit the slides once they’re uploaded — I’m not sure I caught all the nuances of how they use NATS for cache-based lookups versus direct filesystem calls.

Atomic Flow: Git for high-stakes projects

Next was a talk I was genuinely excited about: “An efficient Git workflow for high-stakes projects” by Vladislav Shpilevoy.

A nice example of how a talk doesn’t need to be deeply technical to be valuable and draw a crowd. No hype, just objective, experience-driven opinions on good practices. Everything revolved around “Atomic Flow” — a term Vladislav coined (I think).

The three parts of Atomic Flow:

Atomic commits — Each commit should work almost like a standalone “pure function.” Small, contained, side-effect-free commits that introduce easy-to-review logic.
Patchsets — Daily work organized into patchsets with:
- Preparatory commits: Large but simple changes — renames, refactorings, file reorganization. Easy to review despite their size.
- Functional commits: The small atomic changes from point one. Easy to review because of their focused scope.
Linear history — This was mentioned last (maybe to ease people into the idea), but I think it’s the principle that ties everything together. Your main branch should be a straight line. You still have development branches, but when work merges in, history stays linear.

Why does this matter?
- Merge commits break linearity. Learn to rebase.
- There’s an unambiguous “happens-before” relationship between commits.
- You can check out the entire project at any given moment and investigate confidently.
- Each commit is easily cherry-pickable and revertible.

Vladislav shared examples of Atomic Flow at different companies he’s worked at. He showed how git-blame and git-bisect become dramatically more useful with a clean history. He also mentioned One Flow, an alternative workflow worth exploring.

One honest note from the presenter: this isn’t a panacea. At the boundaries — very small startups moving fast and very large enterprises with complex governance — Atomic Flow becomes harder to enforce. But for the middle ground, it’s worth considering.

Lessons from Homebrew’s longest-running maintainer

The Package Management devroom was predictably packed for Mike McQuaid’s talk on “Package Management Learnings from Homebrew.” We stood the entire time, and my notes are sparse as a result. But I’m also not deep into package management as a discipline — I was there because I use Homebrew daily and wanted to hear from its longest maintainer. Mike also wrote Git in Practice and speaks regularly about open source sustainability and governance.

The talk had friendly banter and delivered what felt like timeless advice about writing and maintaining software for the art of doing it. (The “art” framing is my interpretation, but it captured the spirit.) He touched on lessons about user expectations, what Homebrew has learned from other package managers, and what those managers might learn from Homebrew.

If you use Homebrew and haven’t looked into its governance or the decisions behind its design, Mike’s writing and talks are a good starting point.

Zero-downtime PostgreSQL upgrades at GitLab

This was a GitLab talk that went deep into how they handle zero-downtime PostgreSQL and OS upgrades. The presenter, Alexander Sosna, was upfront: the approach he described is overkill if you can tolerate some downtime. But GitLab can’t afford even a minute of downtime for their production databases.

The upgrade landscape:

pg_dumpall — The most straightforward approach but requires downtime and is slow. For GitLab’s roughly 40 TiB database, they estimated it would take 24+ hours.
pg_upgrade — Ships with every PostgreSQL version. Solid out-of-the-box, but doesn’t create a perfect carbon copy (indexes may need rebuilding), and it’s still not zero-downtime.
pg_upgrade + logical replication — This enables zero-downtime upgrades. The only constraint is that DDL operations (DROP, CREATE, ALTER TABLE) can’t happen during the upgrade, which is usually fine since those can wait.

The switchover problem:

The above worked for a while, but the moment of switchover was a point of no return. GitLab’s solution: bind the switchover with an operation to flip the direction of logical replication. After switching over, the “old version” database starts logically replicating from the “new and upgraded version” database. If things go wrong, they can point applications back to the old version without data loss.

OS upgrades:

One critical caveat: string collation can change between OS versions, which can leave indexes in a bad state. Search for “OS upgrade PostgreSQL collation strings” if you want to see the complexity involved.

Operational details:

Upgrades happen on weekends, with switchover typically on Sundays.
They have up to a day for manual work like refreshing indices.
Extensive testing happens first on a “throwaway” test cluster.
They operate across multiple nodes in at least three availability zones.
Writes are pointed to the upgraded cluster first, then reads are migrated stepwise with constant monitoring.
Most impressively: zero manual actions for the upgrade process itself — everything runs via Ansible playbooks.

Apache Arrow: The hostage negotiator

This was hands-down one of the best talks I’ve heard in a long time. “Apache Arrow, Hostage Negotiator: Revisiting the case for Client Protocol Redesign” was presented by Matthew Topol, co-founder of Columnar (focused on making Arrow accessible) and Apache Arrow PMC (Project Management Committee) member.

The talk combined a clear introduction, a well-articulated problem statement, conciseness, light-heartedness, and effective calls to action. You could tell Matt cared about the subject.

Historical context:

The talk opened with a reference to a 2017 paper from CWI (the same institution that was at the heart of DuckDB’s creation — quack quack!). The paper’s conclusion: legacy client protocols suffer from massive per-row overhead and expensive serialization/deserialization. These protocols were designed when networks were much slower, and OLTP use cases dominated. Database engines have evolved; client protocols have not.

The problem today:

By 2017, client query-fetching protocols for column-oriented databases had stagnated. Meanwhile, average network speeds increased nearly 4x in under a decade. This created an ironic situation where the benefits of compressing query results became negligible — sometimes even counterproductive.

Also, almost all query-fetching protocols were row-based. For OLAP column-oriented databases, this meant paying a costly translation tax: columns to rows at source, then rows to columns again at destination.

Enter Apache Arrow:

Arrow combines:

Optional (or no) compression
No data translation (no JSON, no intermediate formats)
Batched data fetching
Native column orientation

As Matt put it: “Arrow is everywhere” — well, almost everywhere. Some databases and engines still lack integration, but it’s already powering more than most people realize.

Recommended reading:

Matt co-authored a two-part blog series that I think is the best introduction to Arrow’s role in data transfer:

I’m hoping the slides get uploaded soon because they illustrated several points well.

Working with filesystems in time series databases

A solid talk by Aliaksandr Valialkin, creator of VictoriaMetrics.

Aliaksandr covered the high-level concepts and design decisions behind VictoriaMetrics (for metrics) and VictoriaLogs (for logs). The presentation touched on write amplification, instant database snapshots, data corruption protection after power outages, Write Ahead Log trade-offs, and reliability in NFS environments.

My only complaint: the talk would have benefited from an extra 5-10 minutes. Aliaksandr had to rush through several slides, and I suspect there were interesting details he couldn’t fully explore. Still, it was a nice introduction to the thought process behind building a time series database from scratch. VictoriaMetrics handles between millions of samples per second easily, with larger clusters managing over 100 million samples per second.

From disks to distributed: Polar Signals’ database evolution

Our final talk of the day. We were tired and needed to catch a train back to Amsterdam, but I’m glad we stayed. It traced the “design cycle” of a real-world product: Polar Signals’ profiling database.

The initial design:

Polar Signals started with a database for stack traces. Their observations about stacks drove the architecture:

Stacks are repeated, immutable, deeply nested, and temporal (timestamp-associated)
They’re non-relational and dynamically columnar (with labels)
All of this pointed toward a columnar format

FrostDB and its evolution:

Their first product was FrostDB, an embedded columnar database built in Go with a custom query engine. Then reality hit as customers pushed it to its limits:

Data loss on power-off — Nodes became large enough that unexpected shutdowns could lose data. Solution: add Write Ahead Logs.
Slow recovery blocking reads — Nodes grew larger, and WAL replay became so slow it blocked customers from fresh queries. Solution: replicated writes so queries could hit non-recovering nodes.
Recovery coordination — Nodes grew further due to replicated writes, making recovery even slower. Solution: replay coordination.

Eventually, they had to rewrite.

The modern stack:

They moved away from their custom Go implementation and adopted:

DataFusion for query execution
Apache Arrow for data transfer
Delta Lake for object storage

This worked well until serialization (Arrow to Parquet) and deserialization (Delta Lake JSON to Arrow) became too costly.

Enter Vortex:

The final part highlighted Vortex, a zero-copy columnar data format that addressed the serialization overhead.

The talk was a good illustration of how real products evolve, hitting walls and finding open-source solutions at every turn.

A brief eBPF detour

We also attended two eBPF-related talks. I have essentially zero background in eBPF and wanted to understand what the eBPF was about (the eBPF track was enormous). I didn’t take notes because I was fully focused on following along, but they were interesting introductions to a technology I didn’t know about.

Talks I missed (and want to watch)

Schedule conflicts meant missing some talks I was excited about:

Sunday talks I’m eager to watch

I couldn’t stay for the full two days. But here’s my watchlist for when recordings become available:

Watch from home

If you didn’t know about FOSDEM or couldn’t make it to Brussels, the organizers had set up livestreams from each room, which is an awesome thing to do. These livestreams will hopefully eventually become individual recordings at video.fosdem.org/2026. Every presentation is associated with a room, so to watch it, one just needs to find the relevant room from the schedule and watch away.

Thank you, FOSDEM

Last but not least: a big thank you to the FOSDEM team. Organizing an event of this scale for thousands of attendees from around the world, completely free, is an unimaginably incredible feat!