​Welcome to another edition of South Bay Systems! This time we bring you two wonderful talks: Himank Chaudhary will explain how the queuing infrastructure in Tigris Data was built, and Steve Schirripa will tell us about the challenges of RDBMS extensibility.

​Agenda

• ​6:00 PM: Doors open, food and socializing

• ​6:30 PM — 6:50 PM: Queues in Tigris Talk

• ​6:50 PM — 7:30 PM: RDBMS Extensibility Talk

• ​7:30 PM onward : Community socializing!

​Food and beverages will be provided, courtesy of our hosts, PingCAP.

​​Building a Distributed Persistent Queue on FoundationDB

​Tigris is a globally distributed object storage system where objects are stored all over the world. The system needs to have asynchronous tasks to keep objects cached, redundantly stored, and moved around in response to changes in access patterns.

​To solve this, we built an asynchronous task system on top of FoundationDB, just like our metadata. This simplifies our architecture by letting us enqueue tasks in the same transaction as we insert data, providing us atomicity with all or nothing semantics. This wouldn’t be as easy if we used an external system because we’d need distributed coordination between our database and our message queue. We also wanted to take advantage of our existing FoundationDB clusters and expertise to avoid having to make things too complicated for our SREs. Today I’ll cover how FoundationDB makes this easy, the other advantages it’s given us, and some lessons we learned in the process.

​Speaker Bio

​Himank is the CTO and co-founder of Tigris Data, where he focuses on building the distributed systems that let Tigris' object storage scale seamlessly with its users. Before Tigris, he was the tech lead of Docstore - Uber's distributed database that powered petabytes of data and millions of queries per second across a geo-distributed hybrid cloud.

​The Extensibility Tax: Decisions, Principles, and Lessons from a Year of Teaching MySQL New Tricks

​What does it take to add custom data types and indexes to a database that was never designed for them? Over the past year, we built an extensibility framework for MySQL — and discovered, one by one, every place the codebase assumes it knows all the types that will ever exist.

This talk walks through the design decisions that survived and the ones that didn't. We'll cover why extending MySQL's type system through the type system is impossible, why injecting metadata into existing classes beat every attempt at wrapping or subclassing, and why eight separate comparison code paths all needed interception. We'll look at the surprises — CREATE TABLE and ALTER TABLE being essentially different codebases, SQL features like LOAD DATA and default values that each bypass the layers you'd expect, and non-deterministic query plans exposing latent bugs that only appear on the second execution. And we'll share the principles that emerged: follow the existing patterns exactly, treat backward compatibility as a first-class constraint, and make the Data Dictionary sacred ground.

Whether you're building database extensions, working with large legacy codebases, or just curious about what's hiding inside MySQL, you'll leave with practical lessons about making architectural decisions when the codebase is fighting you at every turn.

​​​Speaker Bio

​Steve Schirripa is the technical co-founder/CTO of VillageSQL. He has a BS from Rutgers and a Masters from Carnegie Mellon University. Prior to VillageSQL, he was a Distinguished Software Engineer at Google, where he worked for ~21 years, serving as the Technical Lead for Bigtable and the Colossus File System.