HPTS 2026 (Day 2 and Day 3)

This is the second half of my HPTS 2026 notes. Day 1 was mostly about AI and the importance of specifications. Day 2 and day 3 cover hardware, object storage, failures, consensus, and lakehouses.

Session 5: Hardware will save us all (chair: Natassa Ailamaki)

The Fastest Way to be the Fastest (Bobbi Yogatama, NVIDIA)

GPUs and databases have a love-hate relationship, and Bobbi listed the three reasons: limited GPU memory capacity, the interconnect bottleneck, and engineering complexity. The first two are being fixed by the hardware roadmap. HBM is getting larger and faster. Interconnects and network fabrics are getting faster. But engineering complexity requires some work. No one is eager to rewrite their database to get it work with a GPU.

Bobbi introduced Sirius, a GPU-native composable analytics engine. It offers a drop-in accelerator for your existing database, with GPU-native execution underneath. MICE is the design principle: modular, interoperable, composable, extensible. Bobbi showed how Sirius plugs into DuckDB with no modification to DuckDB.

The other design lesson from Bobby is to spend compute to save memory. On a GPU, compute is the abundant resource and memory capacity and bandwidth are the scarce ones, so the classic tradeoff needs to flip here. It is best to compress the data, compress everywhere, and operate on the compressed data. 

The Next Watt Saved Won't Come from a CPU or a GPU (Devashish Purandare, Microsoft)

Datacenter power consumption is the bottleneck in building datacenters right now. Where is the power consumed? Tax cycles are 60-80% of all execution. There is datacenter tax: compression, crypto, data movement, memory allocation, protocol and RPC handling. Then there is also system tax: error handling, checksums, filesystems, kernel, STL, networking, multithreading. Unfortunately, no single category dominates, so there is no single high value thing to fix.

So how do we fix this? Dev titled his next section: how I learned to stop worrying about Amdahl's law and love the accelerator. Again, unfortunately, both on-chip accelerators and off-chip accelerators have big drawbacks. On-chip you are stuck with whatever the CPU vendor gave you. Off-chip you pay to get data there and back. Dev's answer to this is yes. Cluster smaller accelerators together. That brings us to the fungible DPU, from the company Fungible, which Microsoft acquired and which is now the Azure Boost DPU. Six cores times four threads, and every task gets its own dedicated accelerator. If the tax is spread across a dozen categories, you need a dozen accelerators, not one big one.

Hardware alone won't save us, but hardware/software codesign can. The software side is a data path programming model with work-unit based development. Offload the repetitive, avoid the coordination, optimize the rest.

Using DPU-based SmartNICs for Database Management (Phil Bernstein, Microsoft Research)

Phil also covered the same topic, but more broadly. SmartNICs offload tasks the CPU would normally do. There are three kinds: ASIC-based, FPGA-based, and SoC-based, which are the DPUs. A DPU has two halves with opposite characteristics: a multicore CPU (low latency, lower cost, but weaker throughput) and an ASIC for data path tasks such as DMA, compression, encryption, regex (low cost, high throughput, but high latency).

Everyone is shipping them: Fungible, AMD Pensando, NVIDIA BlueField, AWS Nitro. They are deployed in volume in hyperscaler datacenters, maybe millions of units. The natural database use is the pipeline moving data from storage to compute: decrypt, decompress, regex. All data path, all repetitive, all exactly what the ASIC half is for.

Challenge 1: how do you program a DPU? Mostly they run Linux, so you program it like a computer. Their work on DPU-optimized disaggregated storage, DDS at VLDB'24, uses a page-oriented interface: get page from the server, get page at LSN.

Challenge 2: how do we achieve portability across DPUs? This is their VLDB'26 paper. 

What Changes When Memory is Disaggregated? Building a Database to Find Out (Chiradip Mandal, Space-RF.ORG)

I have no notes here.

Session 6: Query Processing (chair: Peter Boncz)

CoddSpeed! Hardware Accelerated Analytics in Microsoft Fabric (Matteo Interlandi, Microsoft)

Privacy Policy of Cloud Data Services is Harmful (Surajit Chaudhuri, Microsoft)

No notes on these two as well.

No more promises: ROI-Guided Resource-Centric System Design (Natassa Ailamaki, EPFL)

Natassa opened with "procrastination is great." Her proposal is to turn everything into a dynamic decision you make at the last possible second, when you have the most data. In her framing the database sits in between the hardware and the applications as the resource broker. Nothing else in the stack has this much visibility into both sides. The application knows what it wants but not what the machine looks like. The OS knows the machine but not the query. Only the database knows both, and so only the database can make the call.

But then there are challenges. Processors compute faster than memory feeds them, and the situation has not improved. We are memory bandwidth bound, and data movement dominates memory efficiency. Memory accesses are energy hungry, and data movement dominates the energy budget. Bandwidth is king: the CXL/DRAM bandwidth gap predicts the slowdown.

This fits well with Dev's talk. He measured 60-80% of cycles going to tax, much of it data movement. Natassa is also finding the same thing: data movement dominates both the time budget and the energy budget.

Her proposal is ROI-guided runtime interleaving. The scan bottleneck cannot be fixed, and it is impossible to make the data movement decision a priori, because the fastest strategy (pushdown, staging, and the rest) depends on the query and the hardware, and too many factors interact to model it well. Here is the key move to address this: the query plan stays fixed, the data movement strategy changes. Don't try to solve this in the optimizer, where you have to guess. Decide at runtime, based on how much the downstream operators actually consume. Procrastinate until you know. A system is only as efficient as its least adaptive component. The static piece in your pipeline sets your ceiling, no matter how clever everything around it is.

Session 7: Object Storage and Open Formats (chair: Rebecca Taft)

Beyond Disaggregated Storage: The Case for Open Storage in OLTP Systems (Sergey Melnik, Databricks)

Sergey's claim: OLTP needs a diff API. The question an external consumer actually asks is "what changed, and how, since this LSN," and there is no good way to ask it. CDC is the current answer, but it is in the wrong shape. His proposal is Differential Change Discovery, which is a pun on CDC. DCD provides net changes with replacement semantics, partitionable and parallelizable, with a system-defined unit of change that could be a row, a block, or a partition. If a row was updated forty times, CDC hands you forty events and you reconstruct the answer, but in contrast DCD hands you the final net change as answer. Sergey argued that a diff API plus open table formats enables a rich third-party ecosystem.

Ex Falso SQL Quodlibet: Excluding the Middle (Chris Douglas, UC Berkeley)

Today's open table formats struggle with concurrent writers because repeatedly rewriting metadata trees creates massive performance bottlenecks, prompting vendors to build centralized commit catalogs that quietly regress lakehouses back into proprietary warehouses where single engines own tables. To fix this, Chris proposes replacing heavy metadata tree rewrites with an append-only shared log where engines simply post compact "intention records". Crucially, catalog state, invariants, and governance policies are stored directly in this same log as declarative logic rules, allowing each engine to deterministically self-police and reject invalid transactions locally. This design achieves shared ownership and asymmetric provisioning, enabling heterogeneous engines to concurrently read and write structured data without needing an active centralized coordinator.   

Operational Benefits of Databases Built on Object Storage (Colin Breck, Tesla)

Colin works on software for the energy products. Megapack battery storage, which matters for renewables and now for datacenters. Solar. Tesla charging, which is 7 MW of solar generation. Routing a car to a charger is a dynamic decision against traffic and outages. All of it is time series: history, recent, series.

But how fast is fast enough? For them, real-time means one second response, and they cannot tolerate ingestion delay. Colin listed six concrete operational challenges with their clustered time series database. Scaling requires weeks of repartitioning. Replication can fail catastrophically. Upgrades are in place. Workload isolation requires running multiple databases. Deletes require expensive recompaction. Data migration requires custom tools.

To address these challenges, they built a time series database on S3. It is log structured. L0 and L1 are Parquet. DuckDB is used only for querying, and it queries the Parquet on S3 directly, without downloading datasets, using projection and filter pushdown. It reads the Parquet footer for schema and min/max statistics and then fetches only the byte ranges it needs. There is no traditional external index anywhere, because Parquet carries micro-indexes in the file format and DuckDB evaluates them at query time. No B-trees to maintain, no secondary index to keep in sync. This helps resolve the six challenges above. S3 handles redundancy and durability, and the rest of the operations were artifacts of owning the cluster. They also run on on-prem object storage, using the S3 API for portability. Nice finishing touch.

S3 is the Future, S3 is the Past (Viktor Leis, TU Munich)

Victor said Snowflake pioneered S3 for analytics. Redshift and Microsoft Fabric followed. Parquet plus Iceberg, datalakes and lakehouses, made S3 the standard for everybody. But what is S3? (What are frogs?) Viktor argues S3 is essentially a million magnetic disks. Files hash-partitioned across them, with erasure coding for durability. It provides 10 ms latency per request, 80 MB/s throughput per request. You get high aggregate throughput only by issuing many large parallel requests from one node; in their experiments, 100 Gbps. Viktor claims that every architectural rule we derived from S3 is actually a rule derived from spinning disks. HDD seek times, therefore caches are necessary. Wide erasure coding, therefore no in-place writes, therefore log structuring is necessary. And, and, therefore large objects and caching. These are disk facts dictating cloud design.

Now, Viktor shows us the promised land. SSDs are getting ridiculously fast. Datacenter networks are amazing (Steinert et al. CIDR'26). So what would an SSD-based S3 change? No need for tiering, no need for caching, no need for large sequential reads, no need to batch writes. Most of the complexity in the modern cloud data stack is there to hide HDD latency, and it would simply be deleted. But there is a catch. SSD versus hard disk cost ration is 5x, up from 3x last year. Though keep in mind that the long-term trend favors flash, since NAND capacity scales faster than HDDs. So SSD-based S3 is the future... (Viktor dismisses S3 Express: "it is so bad, I didn't put a slide about it. With 3 ms latency, it is not close to what an SSD can do.")

In Q&A, Viktor kept strengthening his case for SSD based design. The OLTP consequence of HDD based S3 should alarm people: Iceberg on S3 achieves about 1 transaction per second (Ginter and Leis, VLDB'26). So every system that wants OLTP on object storage ends up implementing its own flash-based storage or caching service. Everybody is building the same missing layer, separately. However, an SSD local cache is dumb, you destroy the drives like crazy! The right answer is of course an SSD-based object store, not an SSD cache in front of an HDD-based one.

Session 8: Failures Considered Harmful (chair: Atul Adya)

Real Life is Uncertain. Consensus Should Be Too! (Reggie Frank, UC Berkeley)

I wrote about this work earlier here: https://muratbuffalo.blogspot.com/2025/07/real-life-is-uncertain-consensus-should.html

Advancing Storage Efficiency in Replicated Databases (Scott Andreas, Apple)

Replication directly multiplies the cost of your system. This is very problematic for Apache Cassandra deployments with dozens of petabytes. Scott's goal is to aggressively cut this storage cost, while providing the same level of durability.

Let's start with the metric: physical storage provisioned divided by logical bytes stored. Where does that extra storage go? It goes to the replication factor, compression, LSM overhead, commitlog/WAL, and scratch space or headroom. A default deployment is 3x replication, 50% compression, and 30% reserved for maintenance and scratch. That's a lot, but through the rest of the talk, Scott kept cutting that cost.

Witness replicas. Journal-only replicas that participate in the quorum without storing the full dataset. The idea goes back to a 1986 Paris paper, and it gives you availability and durability without the storage. Implementing it in Cassandra required changing repair: conventional repair scans all data, builds Merkle trees, and exchanges deltas, which a witness cannot do because it has no data. The replacement is mutation tracking and reconciliation, analogous to read repair, with background reconciliation feeding hints. That takes the ratio from 6.2x to 4.2x.

LSM efficiency, by reducing the buffers. Tablets: splittable, reassignable ranges, which improve elasticity. The efficiency win comes from making moves and compactions cheaper, which shrinks the headroom you must reserve. 4.2x to 3.6x. Compression advances: 3.6x to 2.4x. Satellite datacenter: two durable replicas across two regions plus a satellite. 1.6x!

Retry is an open problem (Peter Alvaro, UC Santa Cruz and AWS)

Retry causes a storm in a jar: metastability! The industry view is "thank you for the papers, but these retry storms keep happening." The postmortem party goes something like this: the timeout was too aggressive (queue_bound times service time), the queue bound was too high, the token bucket was misconfigured, we should just over-provision, or eliminate the lines so there is no head-of-line blocking (LIFO versus FIFO). Each explanation may have some local truth to it, but none of them resolves things. 

Simulation helps by helping you measure: success rate, latency, queue depth, offered load, effective load, amplification. But how do you calibrate the simulation? That is hard.

Peter argued that we need to prove things about actual code, and pointed at Rupak Majumdar's Descartes, which runs actual code at high speed. He is also chasing other directions : a single-program view (Hydro and Cress) which enables global reasoning about configuration.

MESSI: Reasoning about Performance and Metastability (Aleksey Charapko, UNH)

Queueing theory is the standard tool for perfromance modeling. You can model MultiPaxos and Raft this way. But you get a spherical cow in a vacuum. Real systems are dynamic, have cross-component interactions, and run concrete algorithms with concrete details that matter.

So Aleksey built MESSI, a metastability simulator. Nodes, processors, and a qitem as the basic unit of work, with execution control to express the dynamics the closed-form models cannot. He showed a case study from applying MESSI to MongoDB 9 Atlas intelligent workload management to avoid the convoy effect with two queues separating short and long tasks.

Tuesday Night Panel - AI and Systems

The panel consisted of Anastasia Ailamaki (EPFL), Qian Li (DBOS), Carsten Binnig (TU Darmstadt), Ippokratis Pandis (Databricks), and Sailesh Krishnamurthy (Google). The panel stirred a controversy around code review. A lot of people lined up to profess their views and it was getting very heated. I choose to sit down and listen. This is a very complex topic. I had came to HPTS to see how my peers have processed the AI shock. But the panel discussions showed that people have not processed the AI trauma yet. We are all going through it together.

Session 9: Distributed Systems Are Hard! (chair: Justin Levandoski)

Please Implement A Quorum Database (Alex Miller, Oracle)

This was a fun talk  with a running evaluation question: can it CashDB? Meaning, can this algorithm actually run the workload a real database has? The talk considered a quorum database, like Cassandra: leaderless replication, no downtime from leader failure, majority quorums. The wishlist for anything that wants to replace what we have are survive contention, consistent local snapshot, and incremental catch up. The last two are the ones papers never mention but operators cannot live without.

Then began the tour of candidates. 20 protocols in 20 minutes. Megastore, single-synod Paxos. EPaxos, consensus over graphs: can it CashDB? No.

QuePaxa, including QuePaxa over logs. 7 RTT is painful, and the open question is how to pipeline it. Cloudflare is trying to push this into production, which makes it more interesting than a paper.

RIOT, consensus over graphs: can it CashDB? Probably. Slow path latency equal to Raft, but 10x the network bandwidth.

CEP-15, fast general purpose transactions, with efficient replication, Tempo, and Accord: can it CashDB? Yes.

TAPIR: SurrealDB is putting it into production.

Exploiting commutativity in consensus, Ousterhout's CURP. Jetpack and nil externality. And a surprise appearance from the escrow transactional method from the 1980s, now as high throughput escrow for replicated databases. It can CashDB.

Among the audience, a very small group of distributed systems nerds knew all these protocols. A lot of preparation must have gone into this bespoke talk. It was a lot of fun. I can watch this talk again.

Til Depth Do Us Part: Commitments and Determination (Joseph Hellerstein, UC Berkeley and AWS)

Joe started all the way back with Jim Gray's definition/formalization of transaction. The concept derives from law, specifically marriage. A commitment, made publicly, that cannot be unilaterally undone, witnessed and sealed by an authority. But ambiguity and nondeterminism are inherent in distributed systems, which makes implementing transactions challenging.

Joe argued that semantic specifications are too dumb, just input to output. They cannot express what matters. There is a moment at which the inputs stop being negotiable, and the standard i/o spec has no vocabulary for that moment.  (I need to think more about this. A high level spec may leave that out, but I don't see why a more refined spec would not be able to include this.) Joe argued a spec may have to commit a seal, in the sense of the minister sealing the input.

He wants three things in this framework: decision, complexity, and provenance. He calls it a commitment-centric formulation. He focused only on the decision question for this presentation. 

The decision question is: is coordination avoidable? And we already have a good lineup here. CALM: coordination-free consistency iff the spec is monotone Datalog.  CRDTs: coordination-free consistency if a join semilattice. Functional CALM: coordination-free consistency iff the spec is any monotone function, with sealing the input as a Hoare preorder. Complete CAP: CAP holds iff the spec is monotone.

Sealing is what lets you say "this input set is final," which is what turns a non-monotone problem into a monotone one. Joe argues that this is why it belongs in the spec and not in the implementation. He also showed a hierarchy at the end: consensus is a single commitment, transactions are linear commitments. The depth of that commitment structure is what the title is about. I will wait for their paper to appear to understand this better. This was a great talk.

Autoscaling Is Not just a Resource Allocation Problem (Sacheendra Talluri, ClickHouse)

No notes. Listing it for completeness.

Durable Execution: An End Run on the End-to-End Principle? (Johann Schleier-Smith, Temporal Technologies)

Durable execution is the latest attempt at an old goal (Phoenix and David Lomet's "Application Recovery: Advances Toward an Elusive Goal" at MSR), and the benefits are all about the programmer rather than the system: readable control flow, local reasoning, scoped error handling, fewer bugs, less code. The end-to-end argument says reliability belongs at the endpoints, because the middle cannot know what correctness means. But a question in Q&A observed that durable execution puts recovery in the middle, in the runtime. This is an interesting open question.

Session 10: Lakehouses vs HTAP, the showdown (chair: Natacha Crooks)

Lakehouses don't cut it (yet) (Stefano Stefani, Goldman Sachs)

Stefano works on digital transformation at Goldman, post Sybase liberation day, and he framed it as a Goldilocks problem with no right option: OLTP is isolated from the analytical platforms, the lakehouse is great for analytics but not fresh enough, federation is too slow. Let's say a client is on the phone, so the trader needs position and risk data now, and that means a join, over fresh data, fast. Any one of those is easy but all three together is the problem. Stefano says they need a single source of truth with zero copy reads, transactional isolation, and schema evolution.

Lakebases & Lakehouses => LTAP (Ippokratis Pandis, Databricks)

Ippo started with what actually changed: intra-datacenter bandwidth went 10 Gbps in March 2015, 3200 Gbps in July 2023, 6.4 Tbps now, and every assumption about keeping compute near data was priced against the old number. Then the barbarians came, and AI's impact on OLAP is a new access pattern. Rethinking analytics, they hit a wall at around one second and could not beat it. The accepted wisdom is to copy your data into a separate real-time layer for sub-100ms, ClickHouse or Pinot, but then the data is not fresh, complexity grows, and governance breaks, see earlier talk(s). Ippo then talked about Lakehouse/RT, powered by Reyden: tens of thousands of concurrent queries at sub-100ms directly on live Delta and Iceberg tables, Unity Catalog governance intact, no sync pipelines, granular autoscaling down to zero. He also talked about OLTP side and Neon and argued that being able read at an LSN straight out of storage gives a way for OLTP and OLAP workloads to stop fighting over the same machine.

No, HTAP in the Cloud Is Not Solved. The Industry Traded Freshness for Scalability and Called It Innovation (Daniel Ritter, SAP)

No notes, but the title was the argument.

Becca Taft, who joined MongoDB Research to become our colleague, is co-chairing HPTS'28 with Prof. Natacha Crooks. I will look forward to it, if we are still around by then.