Agenda
Agenda
Day 1
Day 1
Registration, Ground Floor
Coffee served in Foyer
Registration, Ground Floor
Coffee served in Foyer
Registration, Ground Floor
Coffee served in Foyer
Running Start
Running Start
Talk by Prof. Hannes Mühleisen
Co-Creator | DuckDB
Talk by Prof. Hannes Mühleisen
Co-Creator | DuckDB
Building a Distributed Protocol
Distributed protocols are the foundation of scalable and reliable systems — yet we often get lost in implementation details instead of grounding our designs in systems thinking. This talk offers a different path: we’ll explore how a small set of simple, well-crafted abstractions gives rise to complex, distributed systems. We’ll walk through how we move from foundational ideas to working systems, how we reason across layers to build reliable systems from unreliable components, and how we ensure correctness through formal modeling and deterministic simulation testing. A talk for system thinkers and system builders who want to move beyond ad hoc solutions — toward understandable distributed protocols that power scalable and reliable distributed systems.
Building a Distributed Protocol
Distributed protocols are the foundation of scalable and reliable systems — yet we often get lost in implementation details instead of grounding our designs in systems thinking. This talk offers a different path: we’ll explore how a small set of simple, well-crafted abstractions gives rise to complex, distributed systems. We’ll walk through how we move from foundational ideas to working systems, how we reason across layers to build reliable systems from unreliable components, and how we ensure correctness through formal modeling and deterministic simulation testing. A talk for system thinkers and system builders who want to move beyond ad hoc solutions — toward understandable distributed protocols that power scalable and reliable distributed systems.
Building a Distributed Protocol
Distributed protocols are the foundation of scalable and reliable systems — yet we often get lost in implementation details instead of grounding our designs in systems thinking. This talk offers a different path: we’ll explore how a small set of simple, well-crafted abstractions gives rise to complex, distributed systems. We’ll walk through how we move from foundational ideas to working systems, how we reason across layers to build reliable systems from unreliable components, and how we ensure correctness through formal modeling and deterministic simulation testing. A talk for system thinkers and system builders who want to move beyond ad hoc solutions — toward understandable distributed protocols that power scalable and reliable distributed systems.
Coffee Break
Afternoon Break
Coffee Break
Simplicity Is the New Black: Where Some Chase Scale for Scale’s Sake, Simplicity Is Your Competitive Edge
Lately, we’ve seen a new wave of interest in distributing in-process, in-memory systems – projects like Deepseek’s Smallpond (distributed DuckDB) and DataFusion for Ray are getting a lot of buzz. But let’s be honest: this isn’t a new trend. For decades, “going distributed” (i.e. horizontal scale-out via partitioning) has been the go-to move when things get big, or might get big someday. But here’s the thing: just because something can be distributed doesn’t mean it should be. In this talk, we challenge the idea that “distributed” is the right default. We’ll unpack what really happens when you scale out and show how those tradeoffs can crush performance and developer sanity if you’re not careful. Instead, we’ll explore how to make big problems small and only layer on distributed strategies when it’s clearly the right solution. This isn’t a talk against distributed systems – it’s a talk about earning them. You’ll walk away with a systems-thinking mindset that helps you scale with purpose, not panic. Because sometimes, the smartest way to go big… is to stay small… until you absolutely can’t.
Simplicity Is the New Black: Where Some Chase Scale for Scale’s Sake, Simplicity Is Your Competitive Edge
Lately, we’ve seen a new wave of interest in distributing in-process, in-memory systems – projects like Deepseek’s Smallpond (distributed DuckDB) and DataFusion for Ray are getting a lot of buzz. But let’s be honest: this isn’t a new trend. For decades, “going distributed” (i.e. horizontal scale-out via partitioning) has been the go-to move when things get big, or might get big someday. But here’s the thing: just because something can be distributed doesn’t mean it should be. In this talk, we challenge the idea that “distributed” is the right default. We’ll unpack what really happens when you scale out and show how those tradeoffs can crush performance and developer sanity if you’re not careful. Instead, we’ll explore how to make big problems small and only layer on distributed strategies when it’s clearly the right solution. This isn’t a talk against distributed systems – it’s a talk about earning them. You’ll walk away with a systems-thinking mindset that helps you scale with purpose, not panic. Because sometimes, the smartest way to go big… is to stay small… until you absolutely can’t.
Simplicity Is the New Black: Where Some Chase Scale for Scale’s Sake, Simplicity Is Your Competitive Edge
Lately, we’ve seen a new wave of interest in distributing in-process, in-memory systems – projects like Deepseek’s Smallpond (distributed DuckDB) and DataFusion for Ray are getting a lot of buzz. But let’s be honest: this isn’t a new trend. For decades, “going distributed” (i.e. horizontal scale-out via partitioning) has been the go-to move when things get big, or might get big someday. But here’s the thing: just because something can be distributed doesn’t mean it should be. In this talk, we challenge the idea that “distributed” is the right default. We’ll unpack what really happens when you scale out and show how those tradeoffs can crush performance and developer sanity if you’re not careful. Instead, we’ll explore how to make big problems small and only layer on distributed strategies when it’s clearly the right solution. This isn’t a talk against distributed systems – it’s a talk about earning them. You’ll walk away with a systems-thinking mindset that helps you scale with purpose, not panic. Because sometimes, the smartest way to go big… is to stay small… until you absolutely can’t.
Lunch (60min)
Lunch (60min)
Lunch (60min)
Big Data and AI at the CERN LHC: Navigating the Edge of Scale and Speed for Physics Discovery
The CERN Large Hadron Collider (LHC) generates an unprecedented O(10,000) exabytes of raw data annually from high-energy proton collisions. Managing this vast data volume while adhering to computational and storage constraints requires real-time event filtering systems capable of processing millions of collisions per second. These systems, leveraging a multi-tiered architecture of FPGAs, CPUs, and GPUs, must rapidly reconstruct and analyze collision events, discarding over 98% of the data within microseconds. As the LHC transitions to its high-luminosity era (HL-LHC), these data-processing systems—operating in radiation-shielded caverns 100 meters underground — must contend with data rates comparable to 5% of global internet traffic, alongside unprecedented event complexity. Ensuring data integrity for physics discovery demands efficient machine learning (ML) algorithms optimized for real-time inference, achieving extreme throughput and ultra-low latency.
Big Data and AI at the CERN LHC: Navigating the Edge of Scale and Speed for Physics Discovery
The CERN Large Hadron Collider (LHC) generates an unprecedented O(10,000) exabytes of raw data annually from high-energy proton collisions. Managing this vast data volume while adhering to computational and storage constraints requires real-time event filtering systems capable of processing millions of collisions per second. These systems, leveraging a multi-tiered architecture of FPGAs, CPUs, and GPUs, must rapidly reconstruct and analyze collision events, discarding over 98% of the data within microseconds. As the LHC transitions to its high-luminosity era (HL-LHC), these data-processing systems—operating in radiation-shielded caverns 100 meters underground — must contend with data rates comparable to 5% of global internet traffic, alongside unprecedented event complexity. Ensuring data integrity for physics discovery demands efficient machine learning (ML) algorithms optimized for real-time inference, achieving extreme throughput and ultra-low latency.
Big Data and AI at the CERN LHC: Navigating the Edge of Scale and Speed for Physics Discovery
The CERN Large Hadron Collider (LHC) generates an unprecedented O(10,000) exabytes of raw data annually from high-energy proton collisions. Managing this vast data volume while adhering to computational and storage constraints requires real-time event filtering systems capable of processing millions of collisions per second. These systems, leveraging a multi-tiered architecture of FPGAs, CPUs, and GPUs, must rapidly reconstruct and analyze collision events, discarding over 98% of the data within microseconds. As the LHC transitions to its high-luminosity era (HL-LHC), these data-processing systems—operating in radiation-shielded caverns 100 meters underground — must contend with data rates comparable to 5% of global internet traffic, alongside unprecedented event complexity. Ensuring data integrity for physics discovery demands efficient machine learning (ML) algorithms optimized for real-time inference, achieving extreme throughput and ultra-low latency.
Coffee Break
Coffee Break
Coffee Break
Hello Systems
Sometimes you hear about the amazing escapades of systems programmers who delve into the depths of a niche subject and save the day by fixing impossible bugs and increasing performance by orders of magnitude. These are all great adventures, but usually those are not stories where we feel we could be the protagonist because most of us do not consider themselves "systems programmers". In this talk I will tell you a different story about systems thinking at the application level, one that could very well have anybody in this room as its protagonist. Most importantly, I will tell you a story about software written by developers for developers. In other words, a story where we are both the protagonist and, at times, even the dastardly villain.
Hello Systems
Sometimes you hear about the amazing escapades of systems programmers who delve into the depths of a niche subject and save the day by fixing impossible bugs and increasing performance by orders of magnitude. These are all great adventures, but usually those are not stories where we feel we could be the protagonist because most of us do not consider themselves "systems programmers". In this talk I will tell you a different story about systems thinking at the application level, one that could very well have anybody in this room as its protagonist. Most importantly, I will tell you a story about software written by developers for developers. In other words, a story where we are both the protagonist and, at times, even the dastardly villain.
Hello Systems
Sometimes you hear about the amazing escapades of systems programmers who delve into the depths of a niche subject and save the day by fixing impossible bugs and increasing performance by orders of magnitude. These are all great adventures, but usually those are not stories where we feel we could be the protagonist because most of us do not consider themselves "systems programmers". In this talk I will tell you a different story about systems thinking at the application level, one that could very well have anybody in this room as its protagonist. Most importantly, I will tell you a story about software written by developers for developers. In other words, a story where we are both the protagonist and, at times, even the dastardly villain.
Building Software, Simply
One of the meta values of TigerBeetle is simplicity. Simplicity is hard, but it gets you all the nice things — performance, correctness, maintainability. In this talk, we'll uncover fundamental simplicity in how software is built, tested, documented, and released — seemingly "boring" aspects, which nontheless are a foundation for everything else.
Building Software, Simply
One of the meta values of TigerBeetle is simplicity. Simplicity is hard, but it gets you all the nice things — performance, correctness, maintainability. In this talk, we'll uncover fundamental simplicity in how software is built, tested, documented, and released — seemingly "boring" aspects, which nontheless are a foundation for everything else.
Building Software, Simply
One of the meta values of TigerBeetle is simplicity. Simplicity is hard, but it gets you all the nice things — performance, correctness, maintainability. In this talk, we'll uncover fundamental simplicity in how software is built, tested, documented, and released — seemingly "boring" aspects, which nontheless are a foundation for everything else.
Wrap Up
The Eye Filmmuseum remains open until midnight, attendees can stay on
Wrap Up
The Eye Filmmuseum remains open until midnight, attendees can stay on
Wrap Up
The Eye Filmmuseum remains open until midnight, attendees can stay on
Opening Night Rooftop Event
Exclusively for Premium Ticket Holders, TigerBeetle Team and Speakers
Opening Night Rooftop Event
Exclusively for Premium Ticket Holders, TigerBeetle Team and Speakers
Opening Night Rooftop Event
Exclusively for Premium Ticket Holders, TigerBeetle Team and Speakers
Day 2
Day 2
Registration, Ground Floor
Coffee served in Foyer
Registration, Ground Floor
Coffee served in Foyer
Registration, Ground Floor
Coffee served in Foyer
Running Start
Running Start
Don't Forget To Flush
Every programming language environment has an interface for streaming data. Using real world examples of compression, files, sockets, and network protocols, this talk critically examines a variety of strategies for designing an input/output abstraction. We'll watch the data closely as it flows through the pipeline, as well as examining how error conditions are handled. Finally, I'll draw a non-obvious connection between I/O and multithreading, and explain my evil/genius/ridiculous (take your pick) plan to put ALL I/O behind one massive interface, making a lot of people happy/angry (take your pick).
Don't Forget To Flush
Every programming language environment has an interface for streaming data. Using real world examples of compression, files, sockets, and network protocols, this talk critically examines a variety of strategies for designing an input/output abstraction. We'll watch the data closely as it flows through the pipeline, as well as examining how error conditions are handled. Finally, I'll draw a non-obvious connection between I/O and multithreading, and explain my evil/genius/ridiculous (take your pick) plan to put ALL I/O behind one massive interface, making a lot of people happy/angry (take your pick).
Don't Forget To Flush
Every programming language environment has an interface for streaming data. Using real world examples of compression, files, sockets, and network protocols, this talk critically examines a variety of strategies for designing an input/output abstraction. We'll watch the data closely as it flows through the pipeline, as well as examining how error conditions are handled. Finally, I'll draw a non-obvious connection between I/O and multithreading, and explain my evil/genius/ridiculous (take your pick) plan to put ALL I/O behind one massive interface, making a lot of people happy/angry (take your pick).
New Shared-Log Abstractions for Modern Applications
Shared logs are at the heart of many modern applications. Every cloud provider today offers a shared-log service (e.g., AWS Kinesis, Google PubSub); open-source systems like Kafka, RedPanda and others offer the shared log functionality; many hyper-scalers use shared-log services for metadata. Perhaps surprisingly, despite years of research and the ubiquity of shared logs, all existing shared logs today suffer from high latencies. Our research group at the University of Illinois has been building new abstractions and designs to address the latency challenges in shared-log services. The first abstraction, LazyLog (SOSP 24), is a new shared log better suited for applications like message queues and event-driven databases that demand low-latency ingestion. The second one, SpecLog (OSDI 25), is a new shared-log design that reduces end-to-end latencies for critical applications like high-frequency trading, intrusion detection, and fraud monitoring. In this talk, I will describe the motivation, design, and benefits of these new shared logs.
New Shared-Log Abstractions for Modern Applications
Shared logs are at the heart of many modern applications. Every cloud provider today offers a shared-log service (e.g., AWS Kinesis, Google PubSub); open-source systems like Kafka, RedPanda and others offer the shared log functionality; many hyper-scalers use shared-log services for metadata. Perhaps surprisingly, despite years of research and the ubiquity of shared logs, all existing shared logs today suffer from high latencies. Our research group at the University of Illinois has been building new abstractions and designs to address the latency challenges in shared-log services. The first abstraction, LazyLog (SOSP 24), is a new shared log better suited for applications like message queues and event-driven databases that demand low-latency ingestion. The second one, SpecLog (OSDI 25), is a new shared-log design that reduces end-to-end latencies for critical applications like high-frequency trading, intrusion detection, and fraud monitoring. In this talk, I will describe the motivation, design, and benefits of these new shared logs.
New Shared-Log Abstractions for Modern Applications
Shared logs are at the heart of many modern applications. Every cloud provider today offers a shared-log service (e.g., AWS Kinesis, Google PubSub); open-source systems like Kafka, RedPanda and others offer the shared log functionality; many hyper-scalers use shared-log services for metadata. Perhaps surprisingly, despite years of research and the ubiquity of shared logs, all existing shared logs today suffer from high latencies. Our research group at the University of Illinois has been building new abstractions and designs to address the latency challenges in shared-log services. The first abstraction, LazyLog (SOSP 24), is a new shared log better suited for applications like message queues and event-driven databases that demand low-latency ingestion. The second one, SpecLog (OSDI 25), is a new shared-log design that reduces end-to-end latencies for critical applications like high-frequency trading, intrusion detection, and fraud monitoring. In this talk, I will describe the motivation, design, and benefits of these new shared logs.
Talk by Hillel Wayne
Talk by Hillel Wayne
Talk by Hillel Wayne
Lunch (60min)
Lunch (60min)
Lunch (60min)
Lightning Talks
Hosted by Natalie Vais | Spark Capital
Lightning Talks
Hosted by Natalie Vais | Spark Capital
A Systems View to AI
Our intuition about systems thinking & system architectures have been built & refined over many decades of engineering excellence. Stacked abstractions, where each layer exposes more determinism & a higher plane of reasoning, being a prime example of this. Modern AI challenges some of these ideas. By framing AI as a system, this talk explores a few of these points of tension between traditional system design vs what's needed (or even possible) in AI native systems, with the hope of sparking some discussion in the systems community about expanding our definition of what a system is, what APIs are, and what kind of challenges future system designers might have to deal with.
A Systems View to AI
Our intuition about systems thinking & system architectures have been built & refined over many decades of engineering excellence. Stacked abstractions, where each layer exposes more determinism & a higher plane of reasoning, being a prime example of this. Modern AI challenges some of these ideas. By framing AI as a system, this talk explores a few of these points of tension between traditional system design vs what's needed (or even possible) in AI native systems, with the hope of sparking some discussion in the systems community about expanding our definition of what a system is, what APIs are, and what kind of challenges future system designers might have to deal with.
A Systems View to AI
Our intuition about systems thinking & system architectures have been built & refined over many decades of engineering excellence. Stacked abstractions, where each layer exposes more determinism & a higher plane of reasoning, being a prime example of this. Modern AI challenges some of these ideas. By framing AI as a system, this talk explores a few of these points of tension between traditional system design vs what's needed (or even possible) in AI native systems, with the hope of sparking some discussion in the systems community about expanding our definition of what a system is, what APIs are, and what kind of challenges future system designers might have to deal with.
Coffee Break
Coffee Break
Coffee Break
Jepsen 18: Wait, Are Databases Good Now?
We trust our databases, queues, and other systems to store acknowledged writes, to serve them up later, and to isolate transactions from one another. But can we really trust them? Jepsen combines concurrent, generative tests with fault injection to measure distributed systems safety. We'll learn about Datomic, Bufstream, and TigerBeetle, and show how three unconventional systems ensure--or violate--key safety properties.
Jepsen 18: Wait, Are Databases Good Now?
We trust our databases, queues, and other systems to store acknowledged writes, to serve them up later, and to isolate transactions from one another. But can we really trust them? Jepsen combines concurrent, generative tests with fault injection to measure distributed systems safety. We'll learn about Datomic, Bufstream, and TigerBeetle, and show how three unconventional systems ensure--or violate--key safety properties.
Jepsen 18: Wait, Are Databases Good Now?
We trust our databases, queues, and other systems to store acknowledged writes, to serve them up later, and to isolate transactions from one another. But can we really trust them? Jepsen combines concurrent, generative tests with fault injection to measure distributed systems safety. We'll learn about Datomic, Bufstream, and TigerBeetle, and show how three unconventional systems ensure--or violate--key safety properties.
1000x: The Power of an Interface for Performance
1000x: The Power of an Interface for Performance
Wrap Up
Wrap Up
Questions? Contact marina@tigerbeetle.com
Follow @TigerBeetleDB for updates.
Questions? Contact marina@tigerbeetle.com
Follow @TigerBeetleDB for updates.