Since database performance is so near and dear to ScyllaDB, we reached out to our friends across the community to ensure that a nice range of distributed data systems, approaches, and challenges would be represented at P99 CONF 2026. As you can see from our agenda, the response was overwhelming.
Join us at P99 CONF (free + virtual)
A quick PSA for the uninitiated: P99 CONF is a free 2-day community event that’s intentionally virtual, highly interactive, and purely technical. It’s an immersion into all things performance. Distributed systems, database internals, Rust, C++, Java, Go, Zig, Linux kernel, tracing, AI/ML & more – it’s all on the agenda.
This year, you can look forward to first-hand engineering experiences from the likes of Canva, Palo Alto Networks, Uber, Netflix, Oxide, turbopuffer, TigerBeetle, Lovable, Redis, DoorDash, Disney/Hulu, ScyllaDB, and too many others to list here.
Here’s a sneak peek of some database internals talks you can look forward to at P99 CONF 2026…
Searching 100B Vectors on Object Storage @ 200ms P99
Nathan VanBenschoten, Chief Architect at turbopuffer
How do you search 100 billion vectors – over 200 TiB of dense vector data on object storage – with a p99 latency of just 200ms at >1k QPS? We’ll break down how turbopuffer’s vector search index combines hierarchical clustering with RaBitQ binary quantization to enable consistently fast vector search at web scale.
The Fastest Object Storage Client in the World
Georg Kreuzmayr, Software Engineer at TigerBeetle
TigerBeetle needed object storage. The official SDKs don’t compose with our completion-based event loop or Deterministic Simulation Testing — so we built everything from scratch in Zig: custom DNS, TLS, and HTTP, with static allocation, zero-copy io_uring, and a single thread. The result is 4–10× faster than the official GCP and AWS SDKs. This talk covers the architecture, DST infrastructure, and what it looks like to apply TigerStyle to cloud I/O from first principles.
How to Improve Your Cache Algorithm Using AI
Dor Laor, Co-Founder at ScyllaDB
Everybody knows that AI can code. It can also convert your code to Rust. But can AI write a database? In my session, I’ll share my journey of “vibe coding” the ScyllaDB cache to implement an alternative LRU algorithm and improve our p99 latency. Vibe coding a mature database is very different from vibe coding business logic: intrinsic details like multi-version concurrency control and partitions spanning thousands of rows confuse humans and bots alike, but for those with patience, the payoff is real.
My Fair Shares: Teaching a Flat Scheduler About Hierarchy
Pavel Emelyanov, Principal Software Engineer at ScyllaDB
Seastar’s CPU scheduler divides each shard time between a flat set of scheduling groups proportionally to their shares. This elegant model falls apart as that set grows, since every new group makes the worst-case latency worse. It falls apart for the second time by putting users, who want to configure service-level shares, in direct conflict with developers, who do the same for system-level groups. This talk shows how hierarchical scheduling puts the model back together and keeps it from falling apart further.
Can Everything be an LSM?
Almog Gavra, Co-Founder at Responsive
Database systems are tuned to meet the unique requirements of their workloads, so how is it that many of the faster growing database systems all use the same underlying data structure? This talk covers what an LSM tree is, how it works and why such a simple primitive is so powerful — particularly when building the next generation of database systems on object storage. Finally, we’ll introduce SlateDB, an OSS implementation of an LSM tree that you can use to build data systems of your own.
What a Vector Index Does When You Stop Leaving It Alone
Szymon Wasik, Director Software Engineering at ScyllaDB
How do you measure recall against an index that is changing? This talk will explore that, using the example of ScyllaDB Vector Search with 100M vectors. We’ll walk through where float32, float16, int8 and 1-bit actually sit on the recall/QPS/RAM frontier, and when oversampling or rescoring is worth its throughput. What filtering costs across a selectivity sweep, on global versus local indexes. How long after a write a vector is really findable, at p50 and at the tail. And what happens to p99 and to recall when search runs concurrently with inserts, and then with deletes.
Escaping the Gossip: How DoorDash Built an Infinite-Scale Feature Store
Luigi Tagliamonte, Senior Staff Software Engineer, Core Infra at DoorDash
As machine learning models become more sophisticated, the databases serving their features often become the primary bottleneck. At DoorDash, our Sibyl Prediction Service evaluates up to 900,000 ML predictions per second, requiring massive data correlation with ultra-low latency. When our dataset doubled, our 1,000+ node Redis cluster hit its vertical scaling limits, and the overhead of managing cluster state and gossip protocols threatened our strict latency targets.
This session explores how DoorDash went back to first principles to engineer a “clusterless” ML feature store from the ground up. By separating the data from the control plane using a custom Redis Cluster Manager (RCM) and leveraging Apache Kvrocks on top of RocksDB, we completely eliminated the overhead of shared state.
We will examine the architecture that allows us to serve 130 million HMGETs and retrieve 1.6 billion features per second—all while maintaining a strict 50ms P999 latency.
The Vertical Scaling Wall, and How Valkey Gets Over It
Madeyn Olson, Principal Software Engineer at AWS
The intuitive way to scale an in-memory database is to make it bigger: one process, one huge machine, one eye-watering throughput number. That wall comes fast, though. A single large node means a single large blast radius, longer replication, and waste when your hardware doesn’t match your workload. So you scale out. The problem is that scaling out a cluster has historically been painful: slow slot migration, disruptive rebalancing, and expensive node add and remove operations, which is exactly when an operator least wants to touch the system. So how do you build a system that efficiently balances them both?
An Asymmetric io_uring Backend for Seastar
Marcin Szopa, Jakub Czyszczoń, Witold Formański, Developers at ScyllaDB
Seastar, the open-source C++ framework powering high-performance applications like ScyllaDB, is purpose-built for modern hardware. While Seastar already leverages the popular Linux io_uring interface for asynchronous I/O, recent developments have pushed the architecture even further with the integration of an asymmetric io_uring backend.
In this talk, we will explore how this new backend capitalizes on the asymmetric roles of CPU cores. We will break down the mechanics of dedicated networking cores — examining how they were traditionally utilized, how their roles are evolving, and how we specifically adapted them to handle I/O operations in tandem with io_uring, stripping application cores of this role.
Writing a TSDB from Scratch: Performance Optimization
Roman Khavronenko, Co-Founder at Victoria Metrics
Application Performance Monitoring and Kubernetes monitoring in their current state are pretty expensive. The average VictoriaMetrics installation is processing 2-4 million samples/s on the ingestion path, and 20-40 million samples/s on the read path. The biggest installations account for 100 million samples/s on the ingestion path. This requires being very clever with data pipelines to keep them efficient and scalable by adding more resources. In this session, we’ll explore essential optimizations to maintain database speed such as string interning, caching results, goroutine management and understanding sync.pool. Join us to learn how to optimize your database effectively.
Eliminating Query Latency at Cloud Scale: Heuristic Search Space Partitioning for Multi-Tenant Data
Prashant Pathak, Sr. Principal Software Performance Engineer and Rama Teja Repaka, Principal Software Engineer at Palo Alto Networks
At Palo Alto Networks, broad security queries against hundreds of millions of cloud resource records produced high response times which lead to lower throughput. Traditional fixes — sharding, materialized views — all require schema changes. This talk presents HSSPS (Heuristic Search Space Partitioning System): a query-time optimization layer that logically partitions search space without touching the database schema. Deployed in production and covered by two granted U.S. patents, HSSPS reduced P95 latency by over 95%, increased throughput 8–10×, and cut infrastructure cost by ~50%. A reusable pattern for any multi-tenant system facing the same problem.
Breaking SQLite’s Single-Writer Bottleneck
Pere Diaz, Senior Software Engineer at Turso
Turso is our Rust rewrite of SQLite. It replaces the single-writer transaction model with row-level MVCC—snapshot isolation, optimistic BEGIN CONCURRENT transactions, commit-time certification—plus an io_uring async I/O stack for non-blocking durability. We’ll cover the architecture, the hard parts (checkpointing, conflict handling, SQLite compatibility), and the resulting p99 write latency under concurrent load.
How ScyllaDB Eliminates Read Amplification at Scale
Michael Litvak, Senior Software Engineer at ScyllaDB + Felipe Mendes, Technical Director at ScyllaDB
Not every workload fits the same storage shape. While LSM trees optimize for write throughput and range scans, frequently overwritten data and KV workloads require significant compaction I/O to minimize read amplification in a timely fashion. This talk explores how ScyllaDB built a new storage engine to eliminate LSM traversal entirely, enabling a single deployment to handle both wide-column and key-value workloads without compromise. We’ll cover the motivations behind the design, the tradeoffs it explicitly inherits, and early performance results.
Benchmarking ScyllaDB Native Full-Text Search vs. OpenSearch
Benchmarking ScyllaDB Native Full-Text Search vs. OpenSearchKarol Nowacki, Senior Software Engineer at ScyllaDB
Teams building modern applications often face a common challenge: they have to run an operational database alongside a separate search engine, and build a complex pipeline to keep them synchronized. Handling vector search and full-text search natively using standard CQL eliminates the synchronization headache entirely. In this benchmark-driven session, we take a data-driven look at how native full-text search in ScyllaDB compares with OpenSearch. We evaluate both solutions end-to-end, comparing a standalone search engine against ScyllaDB managing the complete data lifecycle natively.
Keeping Latency Under Pressure: Surviving Connection and Request Storms
Marcin Maliszkiewicz, Technical Lead, Senior Software Engineer at ScyllaDB
In this talk, we explore what happens when ScyllaDB clusters face connection storms and request overload. We’ll look at real-world failure scenarios, the risks hidden underneath the surface, and the techniques used to keep latency predictable under pressure – from memory management and caching to throttling and prioritization.
Well-Designed Databases are CPU Bound
Tyson Brown, Consultant at Thoughtworks
Open any textbook on databases and you’ll quickly learn that databases are slow because they write to physical disks. But with the latest NVMe drives, correct amortisation patterns, Direct I/O and strategic use of fsync, a well designed write pipeline is actually CPU bound. We’ll walk through the optimisations in Celeriant – an open-source event sourcing database built with io_uring, thread-per-core, Rust, and kernel-offloaded TLS – that push durable, replicated writes to more than 500k/sec; 15x Kafka on identical EC2 hardware.
Low Latency at Global Scale: Isolation, Optimistic Concurrency, and Precise Time
Raluca Constantin, Senior Database Engineer at Amazon Web Services
Aurora DSQL is a PostgreSQL-compatible distributed database that pays cross-region coordination cost exactly once — at commit — not per statement. This talk walks through the three architectural bets that make that work: per-transaction Firecracker isolation, optimistic concurrency control, and Amazon Time Sync. Then it traces a real multi-statement transaction end-to-end, showing what each millisecond of commit latency buys you and what drives P99 under contention.
Integrating QUIC into Seastar
Piotr Korcz and Kamil Dalidowicz, Developers at ScyllaDB
Seastar’s RPC has always been bound to TCP, inheriting head-of-line blocking and a separate TLS handshake. QUIC’s independent streams and built-in TLS 1.3 remove these problems, but most QUIC libraries introduce the locking and context-switching that Seastar was designed to avoid. We built a QUIC transport for Seastar on top of ngtcp2’s sans-I/O state machine, then adapted RPC to it twice: 1) as a one-to-one socket replacement, and 2) a QUIC-aware approach that opens a fresh stream per call. Join us to learn what it takes to drive a callback-driven protocol engine from a coroutine-based reactor, where the costs come from, and the packet-loss threshold at which multiplexed streams start being worth it.
