HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols

HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols Farzad Habibi

Juncheng Fang

Faisal Nawab

University of California, Irvine habibif@uci.edu

University of California, Irvine junchf1@uci.edu

University of California, Irvine nawabf@uci.edu

arXiv:2610.00889v1 [cs.DB] 1 Oct 2026

Abstract

Concurrency Control (OCC) [27], Multi-Version Concurrency Control (MVCC) [4, 31], and Serializable Snapshot Isolation (SSI) [6], each encoding a distinct trade-off between blocking behavior, validation overhead, abort rate, and correctness guarantees [64]. Despite this variety, designing a new application-specific CC protocol remains expert-driven and labor-intensive, since engineers must reason simultaneously about correctness under concurrency, performance under target workloads, and implementation correctness, all without automated assistance. Protocol optimizations such as commutativity-aware conflict resolution [38], static transaction analysis [17, 19, 58], and deterministic pre-ordering [16, 53] all require deep knowledge of both the application’s transaction logic and the underlying CC mechanism, making them difficult to scale without domain expertise. LLM-driven agents have recently demonstrated the ability to reason about workloads and protocols, generate executable implementations, and iteratively repair them under feedback [8, 47, 60]. LLM-driven evolutionary frameworks extend this capability by maintaining a population of candidate programs, using the LLM to propose mutations, and selecting survivors via a benchmark harness, enabling automated exploration of complex design spaces that are too large for exhaustive search [2, 37, 43, 46]. These developments raise a question. Can an LLM-driven pipeline design an application-specific concurrency control protocol from scratch, verify its correctness, and optimize it for performance without human feedback in the loop? We answer this question with HakiCC, a two-stage multi-agent pipeline for automated application-specific CC protocol design and optimization. In Stage 1, a multi-agent system takes a target workload as input, designs a protocol tailored to it, generates an executable implementation, and iteratively repairs the implementation until it passes correctness verification. In Stage 2, an LLM-driven evolutionary optimizer refines the verified protocol through repeated cycles of mutation and benchmark evaluation, resulting in an optimized protocol. We instantiate HakiCC on two standard OLTP benchmarks— TPC-C [52] and AuctionMark [14]—producing and reporting five protocols per workload. All ten generated protocols are conflictserializable. Structural analysis across 150 binary design criteria shows that the generated protocols span multiple design families: the five TPC-C protocols generated by HakiCC (SALVO, LP-OCC, PESC, DCOV, SADL) mostly cluster around the OCC/Silo [27, 54] family, with SADL being the exception by combining deterministic pre-ordering with commutative escrow locking. The five AuctionMark protocols generated by HakiCC (TREAD, WGC, HSL, PVL, SAPL) include an MVCC-based design (TREAD), a deterministic partitioned-scheduling design (WGC), two OCC-family designs

Large language models (LLMs) have recently been applied in systems research as a tool to reduce human-intensive engineering effort through cost-efficient automation. Decades of research have produced a rich landscape of concurrency control (CC) protocols, each encoding distinct trade-offs in correctness, throughput, and abort behavior. However, most applications in practice default to 2PL or OCC, because selecting and adapting a protocol to a specific application requires expert knowledge that is rarely available to application designers. This is a wasted opportunity, as an applicationspecific CC protocol can yield significant performance advantages over a generic baseline, but designing one requires deep expertise in CC protocol design. In this paper, we propose HakiCC, an LLM-driven multi-agent pipeline that automatically designs, verifies, and optimizes concurrency control protocols tailored to a given target application. HakiCC provides a two-stage pipeline. In Stage 1, a multi-agent system takes a workload description as input and generates an application-specific CC protocol implementation, which is iteratively repaired and verified for conflict-serializability. In Stage 2, the verified protocol is further optimized for that application through an LLM-driven evolutionary loop targeting correctness and throughput. We evaluate HakiCC on TPC-C and AuctionMark as target workloads, producing and reporting ten application-specific CC protocols. All ten are conflict-serializable after Stage 1; Stage 2 improves throughput for nine out of the ten protocols, with average gains of +50.6% for TPC-C protocols and +92.2% for AuctionMark protocols.

Keywords Concurrency Control, LLM, OLTP

1

Introduction

Concurrency control (CC) is a foundational component of Online Transaction Processing (OLTP) systems, defining how concurrent transactions access shared data while preserving correctness and maximizing performance [5]. Decades of research have produced a rich landscape of protocol classes, each with hundreds of variants, including Two-Phase Locking (2PL) [5], Optimistic Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. SIGMOD ’27, Huntington Beach, CA, USA © 2027 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-XXXX-X/2018/06 https://doi.org/XXXXXXX.XXXXXXX 1

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

Farzad Habibi, Juncheng Fang, and Faisal Nawab

(HSL, PVL), and a 2PL-OCC-Escrow hybrid (SAPL). Stage 2 optimization improves throughput for most of the ten protocols, with average gains of +50.6% for TPC-C protocols and +92.2% for AuctionMark protocols, while maintaining correctness. This paper makes the following contributions. • We introduce HakiCC, the first end-to-end two-stage LLM-driven pipeline that designs, implements, verifies, and optimizes applicationspecific concurrency control protocols. • We demonstrate that the pipeline produces correct protocols. All ten generated implementations pass our conflict-serializability verifier, and Stage 2 optimization improves performance without sacrificing correctness in nine out of the ten cases. • We show that application-conditioned design induces structural diversity across generated protocols, spanning pessimistic, optimistic, versioned, deterministic, and semantic design paradigms, as confirmed by pairwise Jaccard similarity analysis over 150 design criteria. • We describe ten CC protocols generated by HakiCC and catalog the concrete improvements discovered by Stage 2 evolution. Section 2 provides background, Section 3 presents the HakiCC design, Section 4 reports the evaluation, Section 5 describes the ten generated protocols, Section 6 discusses related work, and Section 7 concludes the paper.

2 Background and Motivation 2.1 Database Transactions A database transaction is a sequence of operations executed as a single unit of work, ensuring the ACID properties (atomicity, consistency, isolation, and durability). A concurrent schedule is serializable if it is equivalent to some serial execution of its transactions; conflict-serializability is a stricter form that requires preserving the relative order of all conflicting operations [5]. Concurrency Control Protocols. Concurrency control protocols govern the interleaving of concurrent transactions, ensuring conflict-serializability [5]. Prior work has produced a diverse protocol landscape. Two-Phase Locking (2PL) prevents conflicts by acquiring locks before releasing them; Optimistic Concurrency Control (OCC) [27] defers conflict detection to commit time; MultiVersion Concurrency Control (MVCC) [4] maintains multiple data versions to allow readers to proceed without blocking writers; and Serializable Snapshot Isolation (SSI) [6] extends snapshot isolation to full serializability via anti-dependency tracking. More recent hybrid designs combine primitives from multiple families, for example, pairing optimistic validation with commutative-operation escrow [38] to reduce abort rates on counter-heavy workloads. Despite this variety, designing a new CC protocol remains a fundamentally human-driven process, requiring simultaneous decisions about conflict detection timing, version management, abort policy, and application-specific optimizations that interact in nonobvious ways. Correctness Verification. A candidate CC protocol must be evaluated not only for performance but also for correctness under concurrent execution. For conflict-serializability, correctness can be checked by constructing a precedence graph 𝐺 𝐻 = (T , 𝐸) over an execution trace, where each node is a committed transaction

and each edge (𝑇𝑖 ,𝑇 𝑗 ) represents a conflicting operation pair in execution order [5, 40]. An execution is conflict-serializable if and only if 𝐺 𝐻 is acyclic; a detected cycle constitutes a serializability violation. HakiCC uses precedence-graph cycle detection as its correctness verification mechanism. This check is empirical and schedule-dependent, so passing it certifies serializability on the observed interleavings rather than all of them; we mitigate this with a heavily concurrent verification suite designed to surface unserializable behavior.

2.2

LLM-Driven Agentic Optimization

Agentic Workflows. Machine learning has long been used in systems research to guide design choices, tune configuration parameters, and model workload behavior [22, 26, 35, 39, 55, 56, 61]. More recently, LLM-based coding agents have demonstrated an ability to rapidly prototype implementations, propose algorithmic variations, and repair code under structured feedback, substantially reducing the manual engineering effort required for complex software tasks [1, 7, 8, 28, 47, 60]. These capabilities extend naturally to multi-step agentic workflows, where LLM calls are composed into pipelines that handle tasks requiring iterative reasoning, code generation, and feedback-driven repair. Systems algorithms in general, and CC protocols in particular, are well-suited for automated design because their quality can be evaluated against objective, well-defined metrics such as throughput for performance and conflict-serializability for correctness [10–12]. This closed evaluation loop eliminates the need for human judgment when scoring a candidate, making the labor-intensive process of proposing, implementing, and refining protocols a natural fit for LLM-driven agentic workflows. Evolutionary Frameworks. Beyond code generation, recent work has begun to automate portions of the research process itself, iteratively proposing hypotheses, running experiments, and refining designs through feedback-driven agentic loops. A particularly powerful instantiation of this idea is the LLMdriven evolutionary framework [2, 37, 43], in which an LLM maintains a population of candidate solutions (code, designs, or algorithms) and iteratively improves them through an evolutionary loop. In each iteration, the LLM generates and mutates candidates; an evaluator scores them via tests, benchmarks, or formal verification; and the highest-scoring candidates seed the next round. This loop combines the generative capabilities of LLMs with the systematic coverage of evolutionary search, enabling exploration of design spaces that are too large for exhaustive enumeration and too structured for purely random search. HakiCC builds on this paradigm, applying it to CC protocol optimization rather than initial design. The CC protocols’ design space is structured by design principles; however, it is too large for exhaustive search, making LLM-driven evolutionary refinement a better fit for improving existing protocol implementations against performance benchmarks. Rather than designing protocols from scratch, this evolutionary optimization takes a protocol produced by HakiCC’s agentic design workflow as its starting point and evolves that implementation for performance.

2

HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

3

Serializability Verification

Serializable Implementation

1

Workload Specification

Proposer Agent

Unserializable Implementation [+Feedback ]

Runnable Implementation

Stage 1

Concurrency Control Protocol Proposer

Debug Loop

Larger Models 2

Concurrency Control Design Specification

Generator Agent Concurrency Control Protocol Developer

User

4

Novelty Evaluator Agent

Broken Implementation

Benchmarks

OpenEvolve 6

Evolutionary Coding Agent

Check for performance

5

Concurrency Control Implementation

Stage 2

Optimized Concurrency Control Implementation

Cheaper and smaller models

Figure 1: Overview of the HakiCC two-stage pipeline. Stage 1 (top): the Proposer Agent (○) 1 generates a design specification S from workload input W; the Generator Agent (○) 2 translates S into an executable implementation; the Serializability Verifier (○) 3 checks correctness and returns failure traces to the Generator via a debug loop; and the Novelty Evaluator Agent (○) 4 scores and packages the verified protocol P. Stage 2 (bottom): OpenEvolve (○) 5 iteratively optimizes P against performance benchmarks (○), 6 yielding the final optimized protocol P ∗ returned to the user.

3

HakiCC Design

pipeline consists of four components: a Proposer agent (labeled ○ 1 in Figure 1) that generates a protocol specification, a Generator agent (○) 2 that translates it into executable code, a Serializability Verifier (○) 3 that checks correctness and routes failures back to the Generator agent, and a Novelty Evaluator agent (○) 4 that scores the verified protocol.

We present HakiCC, an LLM-driven multi-agent pipeline that creates, implements, and iteratively improves concurrency control protocols with minimal human intervention. Figure 1 shows the HakiCC pipeline, which operates in two stages: the first designs and implements a correct concurrency control protocol based on application specification; the second optimizes it for performance using an agentic evolutionary framework. While we focus on concurrency control as a concrete and well-scoped target, the pipeline can be adapted to other distributed data management protocols. With minimal modifications to workloads and correctness checks, the same framework supports AI-assisted protocol discovery and refinement more broadly.

3.1

Step 1. The Proposer (○) 1 agent takes W (application-specific workload) as input and generates a protocol specification S, which defines read/write visibility rules, commit logic, expected correctness guarantees, and required metadata. The agent is prompted as an expert in database concurrency control research and design and is given W alongside instructions to design a CC protocol optimized for the given application, in the required output format. The format mandates a protocol name, a core design idea, a performance rationale tied to the target transactions, a correctness justification, and a step-by-step execution description covering transaction begin, read/write operations, conflict handling, and commit/rollback logic. Requiring the Proposer to justify correctness pushes it toward designs it can defend as serializable, leading to more serializable designs. The Proposer is additionally given the protocols HakiCC has already produced for the application and instructed to differ from them, steering generation toward unexplored design space rather than re-generating prior solutions.

Stage 1: Proposal Pipeline

Stage 1 designs and implements a correct concurrency control protocol tailored to a given workload specification—a set of transaction types and a target database schema. The stage takes as input the workload specification and produces as output a verified, conflictserializable protocol ready to serve as an input for the evolutionary optimization in Stage 2. To maximize design quality, Stage 1 employs larger LLMs and typically completes within minutes. 3.1.1 Workflow. Stage 1 takes as input an application specification W—a set of transaction types and stored procedures—and produces as output a verified, executable CC protocol implementation P that is conflict-serializable under the verification suite. We model the pipeline as a stateful directed graph 𝐺 = (𝑉 , 𝐸) [28], where each node is either an LLM invocation or a program execution. The

Step 2. The Generator (○) 2 agent takes S as input and generates an executable implementation P. The Generator is prompted as an expert software engineer specializing in database concurrency control protocols, with instructions to implement the protocol specification 3

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

Farzad Habibi, Juncheng Fang, and Faisal Nawab

Initial Context Message History

{ Protocol Summary Report ( S )} Class < CC_NAME > extends ConcurrencyControl : State : // protocol - specific ( locks , versions , timestamps , ...)

Textual Protocol Design

@Override begin ( database ) → Transaction : // initialize transaction context

Initial CC Code

Verification Feedback

...

Debugged CC Code N

Debugged Verification Feedback CC Code N+1

Context After Compaction

@Override read ( txn , key , database ) → Value : // acquire read permission ; return value Textual Protocol Design

@Override write ( txn , key , value , database ): // acquire write permission ; buffer updates ; apply updates

Initial CC Code

Debug Summary

Debugged CC Code N+1

Figure 3: HakiCC context compaction strategy.

@Override commit ( txn , database ) → CommitResult : // validate ; apply buffered writes ; release state return success | abort

and judge to evaluate it against both established CC designs and the protocols HakiCC has already generated for the application, so that redundancy with either is penalized and the accepted protocols stay diverse. The judge independently scores four dimensions and assigns one penalty, each on a [0, 1] scale, which are accumulated into the final novelty score N (P):

@Override rollback ( txn , database ): // undo writes ; release state

Figure 2: Template for the Stage 1 output: a concrete subclass of the ConcurrencyControl abstract class. The LLM fills in the State block and all method bodies according to the protocol specification 𝑆 produced by the Proposer.

N (P) = 0.40 𝑛 orig + 0.30 𝑛 dist + 0.15 𝑛 impl + 0.15 𝑛 arg − 0.15 𝑝 rebrand (1) where 𝑛 orig is conceptual originality, 𝑛 dist is distance from known protocol families, 𝑛 impl is implementation distinctiveness, 𝑛 arg is originality of the correctness argument, and 𝑝 rebrand ∈ [0, 1] is a penalty assigned if the design merely renames or marginally tunes an existing scheme. The accumulated score N (P) informs termination and restart decisions (discussed in Section 3.1.5).

S as a concrete subclass of the provided concurrency control interface in the codebase. The interface defines five abstract methods— begin, read, write, commit, and rollback (see Figure 2, discussed in Section 3.1.2). If no syntactically valid implementation is extracted, the Generator re-invokes the LLM and iterates until one is produced. The implementation P is then passed to the next step, Serializability Verifier ○. 3 Failures are returned to the Generator for repair. Separating proposal from implementation allows each component to use an LLM suited to its demands: the Proposer can invoke a frontier-class model to maximize design quality, while the Generator can use a model optimized for code synthesis and repair. This decoupling also allows the Proposer to reason about protocol logic without being constrained by implementation details, fostering more structurally diverse designs.

3.1.2 Final Stage 1 Output. Figure 2 shows the template of the Stage 1 output in HakiCC. The output is a complete, runnable concurrency control protocol ready to deploy in our transactional system for verification and benchmarking. It begins with the protocol summary specification S followed by the generated code as a concrete subclass of an abstract class. Enforcing a fixed begin / read /write / commit / rollback interface keeps the output coherent. It simplifies benchmarking and verification, reduces the tokens the LLM must generate, and accelerates the repair loop by confining the task to implementing a single class.

Step 3. The Serializability Verifier (○) 3 receives P and evaluates it against a verification suite of concurrent workloads (detailed in Section 4.1), each executed by 𝑁 parallel worker threads for a duration of 𝜏. Correctness is checked by constructing a precedence graph 𝐺 𝐻 = (T , 𝐸) over the operation trace, where T is the set of committed transactions and (𝑇𝑖 ,𝑇 𝑗 ) ∈ 𝐸 if and only if 𝑇𝑖 and 𝑇 𝑗 have a conflicting operation pair in execution order [5]. An execution is conflict-serializable if and only if 𝐺 𝐻 is acyclic; a detected cycle constitutes a serializability violation. If any workload produces a cycle or a runtime failure, a structured error report—including the trace and cycle description—is fed back to the Generator agent (○), 2 which retakes control and attempts a repair. This generate-andverify loop continues until all workloads pass, at which point the verified P is forwarded to the next step.

3.1.3 Shared Conversation History. All nodes communicate through a shared conversation history 𝐻 . Each node appends its output to 𝐻 ; every subsequent node receives the full accumulated context from all prior steps. This makes all prior outputs visible to every downstream component without explicit routing. Sharing 𝐻 lets each agent consult the reasoning behind earlier outputs rather than only the artifact they produced, so the Generator agent can resolve ambiguities in S against the Proposer’s stated intent and avoid retrying repairs that have already failed. 3.1.4 LLM Context Management. Each repair iteration appends error traces to 𝐻 , causing the Generator’s effective context to grow with the number of iterations. We bound this growth with a context compaction strategy (Figure 3): once |𝐻 | exceeds a configurable token threshold, older debug entries are summarized and dropped, retaining only the original specification 𝑆 and the most recent error feedback. This keeps the Generator’s context size complexity to be 𝑂 (1) in the number of repair iterations.

Step 4. In the next step, the Novelty Evaluator (○) 4 agent serves as the final quality check in Stage 1. This agent scores the verified protocol P by prompting an LLM as an expert database researcher 4

HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols

3.1.5 Termination and Restart. The repair loop is bounded by a maximum iteration limit 𝑘 max . If the Generator agent fails to produce a passing implementation within 𝑘 max iterations, the pipeline discards P and restarts from the Proposer agent with a fresh invocation. A restart is also triggered if the novelty score N (P) falls below a configurable threshold 𝜃 N , enforcing a minimum quality bar on the generated design before it advances to Stage 2.

3.2

synthetic workloads: a banking workload (concurrent fund transfers), a counter workload (read-modify-write increments on a shared counter), and a deadlock workload (cyclic resource-acquisition patterns). The full benchmark configuration is detailed in Section 4. Optimization Objective. Each candidate is scored on two primary dimensions: correctness, which measures the fraction of workload scenarios in which the protocol is conflict-serializable, stall-free, and makes measurable progress over the duration of each run; and throughput, which captures the committed transaction rate across scenarios. The primary optimization target is a combined score:

Stage 2: Agentic Optimization Pipeline

Given the verified protocol P0 from Stage 1, Stage 2 solves the optimization problem: P ∗ = arg max score(P) P ∈Π

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

score = 0.5 · correctness + 0.5 · 𝑇ˆ

(2)

(3)

where 𝑇ˆ is a weighted average of per-scenario throughputs, each normalized by a fixed throughput ceiling. This ceiling is the same for all workloads and set to the system’s throughput capacity for a normal workload, so a protocol that reaches the maximum attainable throughput under a normal workload scores 𝑇ˆ = 1. Scenarios involving the pre-known target application (i.e., the application transaction mix the protocol is being optimized for) receive twice the weight in 𝑇ˆ , biasing the search toward protocols that perform well on the intended use case rather than incidentally on other benchmarks. This joint objective lets the search improve throughput while keeping correctness in view at every step, rather than optimizing performance in isolation and checking correctness only afterward. Because correctness is measured over a small suite of adversarial scenarios, it behaves as a near-binary signal in practice, as a single non-serializable scenario sharply lowers the score and an implementation bug typically breaks several scenarios at once. Starting from a correct Stage 1 protocol, any loss of correctness thus carries a penalty far larger than a plausible throughput gain, so the search is steered toward correct designs while still receiving a gradient from partially correct intermediates. At the end of the run, we filter the population by correctness and return the best-scoring protocol among those that pass all scenarios, so the final design is always conflict-serializable.

where Π is the space of conforming CC implementations (i.e., subclasses of the CC interface that compile and run) and score is defined in Equation 3. This score combines two objectives, the correctness of the protocol and its throughput, so that the search rewards implementations that are both serializable and fast. Rather than treating correctness as a hard constraint on Π, we keep it as a graded term of the score, so partially correct candidates are retained during the search and can still guide it toward a correct, high-performance design; as we detail below, the protocol HakiCC ultimately returns is filtered to be fully conflict-serializable. We implement this search using OpenEvolve [46], an open-source LLM-driven evolutionary framework. The optimizer iteratively proposes mutations of candidate implementations, evaluates them under controlled workloads, and selects high-performing variants to seed the next generation. Evolutionary Search. OpenEvolve agent (labeled ○ 5 in Figure 1) optimizes the Stage 1 protocol through an iterative LLM-driven evolutionary loop. The search maintains a diverse population of candidate implementations using MAP-Elites (Multidimensional Archive of Phenotypic Elites) [36], a quality-diversity algorithm that maps programs to behavioral cells and retains diverse highperforming variants rather than converging on a single local optimum. To prevent premature convergence, the population is split into multiple isolated islands that evolve independently, with periodic migration to propagate discoveries across the population. Within each island, selection balances exploitation of currently high-performing programs against exploration of novel variants. Evolution is diff-based, meaning the LLM proposes targeted, localized edits to the current best program rather than full rewrites. Restricting mutations to diffs preserves the core algorithmic structure established in Stage 1 and confines the search to the neighborhood of a known-correct protocol, directing optimization toward performance improvements rather than rediscovering correctness from scratch.

4

Evaluation

In this section, we evaluate HakiCC on two standard OLTP benchmarks, TPC-C and AuctionMark. We ran the full pipeline on each application and report the first ten protocols it produced, five per workload. For Stage 1, we examine the structural diversity of the generated protocols to assess whether application-conditioned design produces a meaningful spread across the CC design space. For Stage 2, we compare the performance of the generated protocols against each other and against 2PL and OCC baselines.

Evaluation Benchmark Suite. Each candidate is evaluated against a benchmark suite of concurrent workloads (○) 6 that tests both correctness and performance. The correctness workloads check that the protocol remains conflict-serializable and makes progress under different scenarios. The performance workloads use standard OLTP benchmarks—TPC-C [52] and AuctionMark from OLTPBench [14]—each run at multiple contention levels ranging from uniform random access to extreme hotspot scenarios, ensuring that optimized protocols generalize across typical and stress-test conditions. The correctness suite additionally includes three targeted

4.1

Experimental Setup

We describe the evaluation configurations for each stage, the benchmark suite used for both correctness checking and performance evaluation, and the hardware platform. Stage 1 Configuration. All Stage 1 agents (Proposer, Generator, and Novelty Evaluator) are backed by Gemini 2.5 Pro at temperature 0.7 with a context window of up to 120K tokens. The repair loop is capped at 𝑘 max = 50 iterations; if the Generator agent fails to produce a passing implementation within this budget, 5

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

SADL

SSI Silo

Farzad Habibi, Juncheng Fang, and Faisal Nawab

SALVO

SSI

MVCC

LP OCC SSI

MVCC

Silo

Silo

OCC TPC-C Protocols

H-Store

20

40

60

80

20

2PL

40

60

TO

TicToc

Silo

Silo

20

40

60

80

20

2PL

Escrow

40

Silo 60

80

TO

TicToc

20

2PL

TO

TicToc

40

Silo 60

80

TO

40

60

80

2PL Hekaton

Calvin

TicToc

TO

TicToc

SAPL

SSI

MVCC

Silo

MVCC

OCC H-Store

20

2PL

40

60

80

OCC H-Store

20

2PL

40

60

80

2PL

Escrow

Hekaton TicToc

20

2PL

Escrow

Calvin

OCC H-Store

PVL SSI

MVCC

Hekaton Calvin

80

Hekaton TO

Escrow

Hekaton Calvin

60

OCC H-Store

Escrow

40

Escrow

Calvin

OCC H-Store

20

2PL

WGC

SSI

MVCC

MVCC

OCC H-Store

TicToc

TO

OCC H-Store

80

Hekaton

TREAD SSI

Silo

Escrow

Calvin

TicToc

TO

MVCC

60

Hekaton

HSL

SSI

20

40

Escrow

Calvin

DCOV

SSI

MVCC

OCC H-Store

2PL

Hekaton

AuctionMark Protocols

80

Escrow

Calvin

Silo

OCC H-Store

Escrow

PESC

SSI

MVCC

Hekaton Calvin TO

TicToc

Hekaton Calvin TO

TicToc

Figure 4: Design similarity profiles of the ten generated CC protocols against eleven reference CC families. Each radial axis reports the Jaccard similarity (%) between a generated protocol’s design feature vector and that of the reference family. the pipeline discards the current proposal and restarts from the Proposer. A restart is also triggered if the novelty score N (P) falls below 𝜃 N = 0.25 (see Section 3.1.5 for the full termination and restart policy). Stage 2 Configuration. The evolutionary optimization in Stage 2 is configured as follows. We run OpenEvolve for 1000 iterations, evaluating candidates serially. The LLM backbone is Gemini 2.5 Flash (temperature 0.7, max 120K tokens per call), and evolution is strictly diff-based: only localized edits are proposed; full rewrites are disabled. The population is structured as 3 independent islands, each maintaining an archive of 100 MAP-Elites cells within a global population cap of 800 programs. Islands migrate periodically: every 50 generations, 15% of each island’s programs are shared with neighboring islands. The exploration ratio (30%) and exploitation ratio (70%) govern how each parent program is chosen, drawing either a random program from the island or an elite from the archive. Each parent is presented to the LLM alongside 2 inspiration programs sampled from the same island and the island’s 3 highest-scoring programs. Benchmark Suite. Both Stage 1 and Stage 2 use the same benchmark suite, which includes TPC-C and AuctionMark applications, as well as three synthetic workloads targeting specific correctness scenarios: a banking workload (concurrent fund transfers), a counter workload (read-modify-write increments on a shared counter), and a deadlock workload (cyclic resource-acquisition patterns). In Stage 1, the Serializability Verifier runs the benchmark suite within the generate-and-verify loop, checking only for conflict-serializability. In Stage 2, the suite serves as the fitness function for evolutionary optimization, scoring each candidate on both correctness and throughput as described in Section 3. TPC-C Application. TPC-C [52] benchmark simulates a wholesale supplier executing five transaction types across multiple warehouses. Following prior CC evaluation practice [18, 41, 42], we

focus on New Order and Payment, which together account for approximately 88% of the benchmark mix (45% and 43%, respectively) and are short update transactions that place the greatest stress on concurrency control. We use a 50%/50% split between the two transaction types, with 1% of transactions subject to random user aborts per the benchmark specification. We evaluate TPC-C along two independent contention axes. The first is a scalability benchmark: we vary the warehouse count across six levels (very low to extreme), from 64 warehouses (low inter-transaction conflict) down to 1 warehouse (all transactions share the same key space). The second is a hotspot benchmark: we fix the warehouse count at 8 and vary the hotspot intensity across four levels, concentrating accesses onto a small fraction of hot records to stress intra-warehouse contention independently of scale. AuctionMark Application. AuctionMark benchmark from OLTPBench [14] models an online auction platform with a mixed readheavy and write-heavy transaction mix. Key contention points include high-bid records and item-status fields, which are accessed by multiple concurrent transaction types. We run AuctionMark at four contention levels by varying the Zipfian skew parameter applied to item and user access patterns, ranging from low to extreme hotspot concentration. A higher skew concentrates a larger fraction of transactions onto a small set of hot item and user records that directly increases read-write conflict at those rows. Evaluation Environment. The experiments are conducted on cascadelake node of Chameleon Cloud [24]. This machine has 2 Intel Xeon Gold 6242 CPUs at 2.8 GHz with 96 virtual threads and is also equipped with 187 GB RAM and 10 Gigabit Ethernet. We implemented a transactional engine in Java with an inmemory key-value store, in the style of DBx1000 [64], that uses the generated HakiCC protocol as its concurrency control mechanism. Each candidate protocol is evaluated by a concurrent Java benchmark running 64 parallel worker threads. Each scenario runs for 6

HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols

SADL LP-OCC 24 57

HSL 31 54 49 58 57

AuctionMark

80

PESC 33 88 58 DCOV 33 67 56 69

60 40

TREAD 25 42 32 48 46 46 WGC 39 45 26 43 43 38 31 PVL 34 89 59 86 66 56 48 41

Among TPC-C protocols (blue), SALVO, LP-OCC, PESC, and DCOV all cluster strongly around the OCC/Silo/TicToc family (47– 55% on those axes), consistent with optimistic validation designs tailored to short-update workloads. SADL diverges from the rest of the TPC-C protocols, with the highest Escrow (48%) and Calvin (45%) similarity of any generated protocol, which reflects a commutativeoperation and reservation-based design rather than a conventional optimistic approach. Among AuctionMark protocols (orange), PVL is the most Silodominant (59%), while TREAD diverges sharply from the rest with its highest scores on Hekaton (52%) and SSI (48%), indicating a version-based, anti-dependency-tracking design. WGC stands out as the most H-Store-similar protocol (40%), the only partition-style design in the cohort, while SAPL combines a notable Escrow affinity (46%) with broad OCC and Silo characteristics. Protocol Similarity. Figure 5 shows the pairwise Jaccard similarity between all ten generated protocols. This heatmap reveals a tight structural cluster: SALVO (TPC-C), PESC (TPC-C), and PVL (AuctionMark) are nearly identical (≥86% pairwise), with DCOV and LP-OCC also closely related (56–69% to the cluster core). This cluster spans both target workloads, showing that the Proposer can independently converge on similar OCC/Silo-family designs when both workloads reward optimistic execution. Three protocols stand clearly apart from the rest, with SADL reaching at most 44% similarity to any peer, TREAD 48%, and WGC 45%—each representing a design family (Escrow/Calvin, Hekaton/SSI, and H-Store partition, respectively) that no other generated protocol closely replicates. This combination of a tight optimistic cluster and three distinctly separated protocols confirms that Stage 1 produces genuine structural variety rather than uniformly sampling a single region of the protocol space, a spread the pipeline actively encourages by prompting against redundancy (Section 3).

100

Design Similarity (%)

TPC-C

SALVO 37

20 0

SAPL 44 57 53 61 48 41 35 26 59 L O L C C V L D C L SAD SALV LP-OC PES DCO HS TREA WG PV SAP

Figure 5: Pairwise design similarity between the ten generated CC protocols. 30 seconds to collect throughput and correctness traces. Serializability is checked after each scenario using precedence-graph cycle detection.

4.2

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

Stage 1 Results

We ran Stage 1 on TPC-C and AuctionMark and collected the first five protocols produced for each application—SALVO, LP-OCC, PESC, DCOV, and SADL for TPC-C, and TREAD, WGC, HSL, PVL, and SAPL for AuctionMark (described in detail in Section 5). We evaluate two aspects of the ten generated protocols: how their designs align with known CC families and how structurally similar the protocols are to each other. Protocol Diversity. To assess structural diversity, we describe each protocol as a binary feature vector, where each entry records whether the protocol uses a particular design technique (1) or not (0). We define 150 such features, grouped into 12 design dimensions— pessimistic locking [5], optimistic validation [27], conflict detection timing, multi-version storage [4], correctness guarantees, SSI-style anti-dependency tracking [6], timestamp ordering [3], intervalbased commit timestamps [65], deterministic pre-ordering [16, 53], partition-based execution [23], commutativity-aware conflict resolution [38], and implementation-level features. Pairwise similarity between two protocols is computed using a Jaccard-style metric [21] over positive criteria:

4.3

Stage 2 Results

Stage 2 evolutionary optimization improves throughput for the majority of generated protocols across both workloads. Figure 6 shows per-protocol throughput curves before and after optimization for both workloads, with throughput (K TPS) on the 𝑦-axis and contention level on the 𝑥-axis; each protocol is plotted as a Stage 1 and a Stage 2 curve, the shaded band between them marks the improvement, and the 2PL and OCC baselines are overlaid for reference. Figure 7 decomposes execution time into read, write, and commit phases to expose the source of each improvement, reporting the mean per-phase duration (in 𝜇s) for every protocol before and after Stage 2 across four hotspot intensity levels.

|{𝑐 : 𝐴𝑐 = 1 ∧ 𝐵𝑐 = 1}| × 100 (4) |{𝑐 : 𝐴𝑐 = 1 ∨ 𝐵𝑐 = 1}| The score is the fraction of techniques both protocols adopt (numerator) among all techniques used by either protocol (denominator), scaled to a percentage. Shared absences (both 0) are excluded, so similarity reflects genuine structural alignment rather than coincidental non-adoption of features. Figure 4 shows the design profile of each generated protocol as a radar chart, where each axis represents the Jaccard similarity to a reference CC family (2PL [5], OCC [27], MVCC [4], SSI [6], Silo [54], H-Store [23], Escrow [38], Calvin [53], TO [3], TicToc [65], Hekaton [30]). No generated protocol collapses onto a single reference: all ten exhibit a distinct multi-axis profile, borrowing selectively from two to four reference families without reproducing any one of them. sim(𝐴, 𝐵) =

4.3.1 TPC-C Protocols. Throughput Improvement. Among TPCC protocols, Stage 2 produces the largest gains for SADL and PESC, moderate contention-dependent gains for SALVO, and marginal changes for LP-OCC and DCOV (Figure 6). SADL improves by 52 − −406% across all six contention levels, the largest absolute gains in the TPC-C cohort. SALVO shows a modest regression at very low contention (−7%) but strong gains at high and extreme contention (+85% and +145%), consistent with optimizations that pay off only when the commutative-write fast path is heavily exercised. PESC shows a −15% regression at very low contention but recovers to +77–203% at higher levels, reflecting commit-path optimization 7

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

300 -7%

250

250

200

200

150

150

100

100

+196% +215%

+52%

50

+136% +373% +406%

0 w Very Lo 1400

LowMedium HigVhery HighExtreme

SALVO (Stage 1) SALVO+ (Stage 2)

350

+99%

250

250

200

200

+23%

300

50 0 w Very Lo

+145%

LowMedium HigVhery HighExtreme TREAD (Stage 1) TREAD+ (Stage 2)

1200

0 w Very Lo 1400 1000

800

800

-8%

600

-4%

400

-7%

+480%

200

+106%

0 Low

e

High

Medium

Extrem

High

Medium

+91%

e

Extrem

+6%

+1%

+77%

0 w Very Lo 1400

WGC (Stage 1) WGC+ (Stage 2)

PVL (Stage 1) PVL+ (Stage 2)

+27%

+435%

+282%

1000 +11%

400

400

200

200

200

2PL

OCC

High

0 Low

e Extrem

Medium

High

SAPL (Stage 1) SAPL+ (Stage 2)

1000

+30%

400

Medium

+6%

LowMedium HigVhery HighExtreme

1200

600

0 Low

-6% +9%

0 w Very Lo 1400

800

+11%

-10%

50

600

+14%

+1%

-19%

100

LowMedium HigVhery HighExtreme

1200

+24%

150 +13%

800

600

400

200 0 Low

-21%

200 +177%

+18%

-32% -1%

0 Low

e Extrem

-2%

Medium

Improvement range

High

AuctionMark

1000

250

50

LowMedium HigVhery HighExtreme

1200

800 600

+4%

DCOV (Stage 1) DCOV+ (Stage 2)

300

+203%

100

+6%

350

PESC (Stage 1) PESC+ (Stage 2)

+103%

150

50

1000

300 -15%

-8%

100

+85%

350

LP-OCC (Stage 1) LP-OCC+ (Stage 2)

+12%

150

+9%

1400

HSL (Stage 1) HSL+ (Stage 2)

1200 -14%

Throughput (K TPS)

350

SADL (Stage 1) SADL+ (Stage 2)

300

TPC-C

Throughput (K TPS)

350

Farzad Habibi, Juncheng Fang, and Faisal Nawab

e

Extrem

±% = throughput change (Stage 1 Stage 2)

Figure 6: Throughput in thousands of transactions per second (K TPS) before (Stage 1) and after (Stage 2) evolutionary optimization across six contention levels for TPC-C protocols and four contention levels for AuctionMark protocols. Shaded area shows the improvement range; 2PL and OCC baselines shown for reference. Percentages denote the per-level throughput change from Stage 1 to Stage 2.

Low Medium

High Extreme

Read Phase

101

100

6.0 0.8 79 1.4 0.7 0.5 1.0 0.7 1.2 1.1 0.9 1.2

Low Medium

7.7 18 0.5 0.5 269 2,460 1.2 3.3 0.6 0.5 0.6 0.5 0.6 0.7 0.7 0.7 0.7 0.8 1.0 0.7 0.7 0.6 0.9 0.6 High Extreme

Write Phase

AuctionMark 103

102

101

100

22 187 372 125 79 67 101 104 209 25 263 257

21 405 397 172 120 67 197 182 553 30 400 437

Low Medium

20 22 646 507 539 670 151 279 245 1,899 230 782 364 543 348 541 891 750 180 549 434 995 488 949

2PL OCC HSL HSL+ TREAD TREAD+ WGC WGC+ PVL PVL+ SAPL SAPL+

103

102

High Extreme

12 5.4 5.1 5.2 1.5 6.2 1.7 1.8 4.1 4.4 7.3 6.1

89 3.2 4.1 6.5 0.9 1.9 1.8 2.1 2.2 3.7 4.1 5.1

Low Medium

Commit Phase

123 1.8 2.9 3.3 1.1 3.4 1.5 1.7 3.6 2.4 4.4 3.9

184 1.5 3.7 14 0.6 1.4 1.2 1.3 4.7 1.9 9.8 6.8

High Extreme

Read Phase

102

101

100

9.6 4.5 2.5 3.2 1.3 3.2 0.8 0.9 1.9 1.8 7.7 6.3

9.0 2.9 2.8 4.6 0.7 1.3 0.9 0.8 1.6 1.9 5.0 5.0

Low Medium

12 1.7 2.2 2.4 1.1 1.3 0.9 0.8 1.7 1.4 5.0 4.2

17 1.4 2.4 4.2 0.6 1.1 0.8 0.7 3.1 1.3 5.3 3.8

High Extreme

Write Phase

101

100

17 16 20 28 46 125 143 306 14 44 94 143 20 25 92 127 76 1,204 1,586 2,412 77 296 367 307 88 79 87 128 81 59 77 115 31 57 177 239 23 26 28 22 22 47 30 72 25 27 76 103 Low Medium

103

Duration (µs, log)

102

4.4 1.0 50 1.2 0.9 0.6 0.9 1.1 1.0 0.8 1.0 1.6

Duration (µs, log)

118 0.9 28 289 1.0 1.1 60 63 1.7 1.6 1.1 0.8

Duration (µs, log)

38 1.4 33 89 1.8 1.7 42 39 2.4 3.2 1.7 1.6

Duration (µs, log)

25 1.9 33 59 2.9 2.1 23 22 3.9 3.0 2.4 2.5

Duration (µs, log)

12 2.8 37 19 3.4 3.2 10.0 11 3.5 2.7 2.6 3.3

Duration (µs, log)

TPC-C 2PL OCC SADL SADL+ SALVO SALVO+ LP-OCC LP-OCC+ PESC PESC+ DCOV DCOV+

102

High Extreme

Commit Phase

Figure 7: Mean read, write, and commit phase duration (𝜇s) for all protocols before and after Stage 2 optimization, at four hotspot intensity levels. A + suffix on a protocol name denotes its post-Stage 2 variant. that carries overhead at low concurrency. LP-OCC and DCOV show near-flat or slightly negative changes (−19% to +13%), indicating that Stage 1 already found a near-optimal implementation for these OCC-family designs. All five TPC-C protocols outperform both the 2PL and OCC baselines at medium and higher contention levels after Stage 2.

deltas reflect implementation maturity rather than missed optimization opportunities. The OCC baseline exhibits a characteristic validation bottleneck in the commit phase (187–646 𝜇s), while 2PL shows an escalating read phase (12–118 𝜇s) under increasing contention due to lock-wait latency. 4.3.2 AuctionMark Protocols. Throughput Improvement. The AuctionMark cohort exhibits a wider range of Stage 2 outcomes than TPC-C (Figure 6). TREAD undergoes the most dramatic recovery: a −21% regression at low contention is accompanied by +480%, +106%, and +91% gains at medium, high, and extreme contention, transforming a protocol that was barely functional at moderate contention into the highest-throughput design in the AuctionMark cohort at those levels. PVL improves monotonically with contention—+11% at low, +282% at high, and +435% at extreme— becoming the best-performing AuctionMark protocol at high and extreme contention after optimization. WGC shows consistent modest improvements of +1–24% across all levels, reflecting incremental refinements without any single dominant fix. HSL degrades slightly at all four levels (−4% to −14%), the only AuctionMark protocol

Phase-Level Analysis. Figure 7 reveals that the large SADL improvement originates from a critical write-phase defect: the Stage 1 SADL implementation exhibits a write phase of 50–2,460 𝜇s across contention levels, growing catastrophically to over 2 ms at extreme hotspot contention. Stage 2 identifies and eliminates this write-path bottleneck, reducing the write phase to 1.2–3.3 𝜇s, a 3 orders-ofmagnitude improvement at extreme contention. PESC undergoes a similarly dramatic commit-phase transformation: the Stage 1 commit overhead of 209–891 𝜇s is reduced to 25–549 𝜇s after Stage 2, with the low-contention case dropping by 8×, reflecting the elimination of redundant validation work on the conflict-free fast path. In contrast, LP-OCC and DCOV phase times are largely unchanged between Stage 1 and Stage 2, confirming that the small throughput 8

HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols

where Stage 2 produces a net negative outcome. SAPL gains +18% at low contention but regresses by 32% at high contention, indicating that Stage 2 mutations that benefited the low-contention case introduced a new bottleneck under high concurrency. Phase-Level Analysis. Figure 7 identifies the commit phase as the dominant bottleneck in the AuctionMark cohort, mirroring the TPCC findings. TREAD’s Stage 1 commit phase grows from 76 𝜇s at low contention to 2,412 𝜇s at extreme—a super-linear growth in commit overhead under increasing contention. Stage 2 reduces this to a flat 77–367 𝜇s profile, eliminating the super-linear scaling behavior and enabling the large throughput recovery observed in Figure 6. PVL shows a complementary pattern: its Stage 1 commit phase grows to 239 𝜇s at extreme contention, while Stage 2 achieves near-constant commit overhead of 22–28 𝜇s across all levels—comparable to the 2PL baseline—explaining the +435% throughput gain at extreme contention. HSL, WGC, and SAPL exhibit commit phases in the 14–143 𝜇s range even at Stage 1, leaving little room for commit-path optimization; the modest throughput changes for these protocols are consistent with this observation. Read and write phase times remain below 10 𝜇s for most AuctionMark protocols across all contention levels, confirming that the bottleneck is exclusively in the commit phase rather than in data access or buffer management.

5

scheduler drains this queue in strict IPSN order, applies buffered writes, and releases locks. Deadlocks are prevented because a transaction may wait for a lock held by another only when its IPSN is larger, producing an acyclic waits-for graph. Stage 2 Improvements. The optimizer fixed an IPSN assignment race that allowed duplicate sequence numbers, an initialization error that caused partitions to share a single scheduler, and a missing wake-up of waiting transactions in the per-partition commit scheduler that produced head-of-line blocking under burst loads. All three are low-level concurrency defects that suppressed throughput rather than algorithmic changes; removing them unlocked the per-partition and OC-lock parallelism the design already intended, accounting for SADL’s large throughput gain. 5.1.2 SALVO – Semantic-Aware Latching and Optimistic Delta Application. SALVO is a hybrid OCC protocol that dispatches each read and write to one of three specialized modes selected by runtime key-pattern matching. District-level order counter fields are served by lock-free atomic increments. Customer balance reads that are unconditionally overwritten by the same transaction are excluded from validation (blind-read elimination). All remaining fields follow standard OCC versioned reads. Three write modes mirror this structure: new-order records are private inserts with version 0, year-to-date and balance fields accumulate commutative deltas, and all other writes are buffered as versioned values. SALVO provides conflict-serializability, combining OCC validation on the optimistic path with order-independent commutative deltas and sorted-order commit locking for deadlock freedom. Read/Write/Commit. A read returns the requested value and records its version for later validation, except on the two fast paths, where counter reads use an atomic fetch-and-add and blind balance reads skip version tracking. A write is buffered locally in its mode— a versioned value, a commutative delta, or a private insert—and applied only at commit. Commit locks all written and delta keys in sorted order for deadlock freedom, validates that no read version has changed, and then installs the versioned writes, applies the deltas atomically, and adds the private inserts before releasing the locks. Stage 2 Improvements. The optimizer widened the commutative delta set from warehouse-level to district-level year-to-date and order-counter fields (the actual hot spots at low warehouse counts) and corrected a double-apply bug that re-applied deltas during checkpoint replay.

Generated Concurrency Control Protocols

In this section, we describe the ten concurrency control protocols generated by HakiCC: five targeting TPC-C and five targeting AuctionMark. Each protocol is described below with its design overview, read/write/commit strategy, and the improvements found by Stage 2. The correctness argument stated for each protocol is the conflictserializability justification HakiCC produced during design and confirmed in Stage 1 verification.

5.1

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

TPC-C Specific Protocols

5.1.1 SADL – Semantic-Aware Deterministic Locking. SADL1 partitions the TPC-C key space by warehouse ID. Each partition is managed by a single-threaded scheduler that assigns each transaction a monotonic intra-partition sequence number (IPSN), establishing a pre-defined serial order. Concurrency is maximized through three lock modes: shared (S) for reads, exclusive (X) for non-commutative writes, and an ordered-commutative (OC) lock for arithmetic writes. OC-locks are mutually compatible, allowing concurrent commutative updates to the same field while the commit queue enforces the IPSN order. SADL guarantees conflict-serializability, as the pre-assigned IPSN fixes a per-partition serial order and applying buffered writes in that order makes the committed state equivalent to a serial execution. Its performance gains rely on a largely partition-friendly workload; cross-partition transactions remain correct but forgo the benefit of independent per-partition scheduling. Read/Write/Commit. Reads acquire an S-lock and return the store value. Writes to order-ID counter fields are non-commutative and acquire an X-lock; all other writes (year-to-date balance updates, stock quantity adjustments) are commutative arithmetic operations and acquire an OC-lock. All writes are buffered locally until commit. Commit places the transaction in a per-partition priority queue; the

5.1.3 LP-OCC – Lock-Protected Optimistic Concurrency Control. LP-OCC is a classic OCC implementation that eliminates readerwriter races on value-version pairs by briefly locking each key during the read phase. Each record has a dedicated per-key lock in a global lock manager. Transactions execute optimistically, buffering all writes locally; the shared store is only modified at commit. LP-OCC provides conflict-serializability, since the read-phase lock makes each read observe a fully installed value and version, and holding locks over the whole read and write set at commit makes validation and installation atomic. Read/Write/Commit. A read briefly locks the key, captures the value and its version together, and releases the lock, so the transaction always sees a consistent snapshot; repeat reads are served

1 All protocol names are generated by the HakiCC Proposer agent (an LLM), not chosen

by the authors. 9

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

Farzad Habibi, Juncheng Fang, and Faisal Nawab

from a local cache. A write is buffered locally, and if the key was not already read, a consistent read is issued first so that every written key carries a version dependency and no update is lost. Commit locks the union of the read and write set in sorted order (keeping it deadlock-free), validates that no recorded version has changed, and, if validation passes, installs the buffered writes and bumps their versions before releasing the locks. Stage 2 Improvements. The optimizer stripped avoidable overhead from the commit path, removing synchronization from pertransaction data structures and redundant allocation when ordering keys for locking. It also routed each write to the store’s matching operation—insert, numeric increment/decrement, or overwrite.

fields compute a signed delta; all other writes buffer an absolute value and mark the transaction as having an exclusive write. A read is classified as blind if the transaction has already performed at least one exclusive write and the key is a customer balance field that will be unconditionally overwritten; blind reads are cached but excluded from counter validation. Commit acquires the perwarehouse commit lock, validates all non-blind read-set entries against both EMC and CMC, installs each write (incrementing EMC for exclusive writes, CMC for delta writes), and releases the lock. Stage 2 Improvements. The optimizer removed synchronization from per-transaction data structures that are never shared across threads, added a validation-result cache to reuse fetched records across the validation and write phases, and fixed partition-key parsing to correctly route global item records.

5.1.4 PESC – Phased Execution and Semantic Commit. PESC is a hybrid concurrency control that routes each write to one of two paths based on key semantics. Year-to-date and balance fields are commutative and accumulate signed deltas; all other fields are noncommutative and buffer absolute values. A per-transaction flag tracks whether any non-commutative write has occurred, enabling a blind-read optimization that skips version tracking for customer balance reads in New Order transactions (which unconditionally overwrite those fields). PESC is conflict-serializable, as the non-commutative path validates reads and then holds write locks through installation so no concurrent commit can interfere, while commutative delta writes are order-independent. Read/Write/Commit. Reads check a local snapshot cache; misses fetch the value and version stamp from the store. Commutative writes compute a delta against the snapshot and merge it into a delta set; non-commutative writes buffer the intended value in a write set. Commit acquires per-key locks in sorted order, validates the read set, re-reads current locked values for stock fields and recomputes their deltas relative to the snapshot (absorbing concurrent writes that committed between the read and the lock), installs all writes, and releases locks. Stage 2 Improvements. The optimizer removed a bypass that routed order-ID counter writes directly through an atomic variable outside the transaction protocol (leaving those writes untracked in version state), narrowed the locking scope to write keys only to reduce contention, and routed every write through the store’s typed insert, update, and increment operations.

5.2

AuctionMark Specific Protocols

5.2.1 HSL – Hierarchical Speculative Locking. HSL groups records into coarse-grained logical entities and enforces concurrency at entity granularity. Transactions execute speculatively in parallel without acquiring any lock during execution; they register read and write intents on entity-level data structures. Concurrency control is enforced entirely at commit through firm-lock acquisition and proactive invalidation of all concurrent speculators on written entities. HSL guarantees conflict-serializability, as a committing writer holds firm locks on every entity it touched and proactively aborts any transaction that speculatively read a written entity, so no transaction can commit on a stale read. Read/Write/Commit. Reads register the transaction in the entity’s speculative-reader map and fetch the value directly from the store without acquiring any lock. Writes register in the speculative-writer map and buffer the key-value pair locally. Read-only transactions (empty write set) skip locking entirely and commit immediately after deregistration. Writing transactions sort their read and written entity IDs lexicographically and acquire each entity’s firm lock in that order. Writes are applied atomically; every transaction that read from a written entity is then proactively aborted before locks are released. Stage 2 Improvements. The optimizer expanded entity-prefix coverage to the full AuctionMark schema (adding item-bid, itempurchase, user-item, and composite counter entity types), reducing false conflicts from unrecognized keys falling through to the single global lock entity, and fixed cleanup to remove transactions from the correct speculative map rather than cross-probing both maps for every entity.

5.1.5 DCOV – Dual-Counter Optimistic Validation. DCOV is a semantic OCC protocol that replaces the conventional single version number per record with two monotonic counters: an ExclusiveModification Counter (EMC) incremented by non-commutative writes and a Commutative-Modification Counter (CMC) incremented by delta writes. Each record is stored as a (value, EMC, CMC) triple. A per-warehouse commit lock serializes all commits within a partition; validation confirms both counters match for every non-blind read key. DCOV is conflict-serializable, since the per-warehouse commit lock makes each transaction’s validation and installation atomic, and matching both counters confirms that no committer has modified its non-blind reads since it observed them. Read/Write/Commit. Reads check the local write set, then a pertransaction cache, then the store. Writes to year-to-date and balance

5.2.2 TREAD – Transactional Read Epoch-based Abort & Deltas. TREAD is a multi-version protocol built on an MVCC backbone, where each key holds a version chain and reads are non-blocking, serving the latest version committed before the transaction’s start timestamp. Item-status reads additionally register the transaction in the read version’s dependency set, while high-contention counter fields—bid-count, rating, and per-item-user counters—bypass the version chain and accumulate as commutative signed deltas. These mechanisms lift MVCC’s snapshot isolation toward serializability, since a transaction that writes a status field aborts the dependents registered on the overwritten version before installing its 10

HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols

own, breaking the anti-dependency cycles behind write-skew, while commutative deltas commit in any order. Read/Write/Commit. Reads walk the version chain for the latest visible version; item-status reads additionally register in the version’s dependency set. Commutative writes append a signed delta to a local buffer; all others buffer absolute values. At commit, each standard write acquires a hash-stripe latch—rather than a lock per record, keys are hashed onto a fixed-size array of latches, so only keys colliding on the same entry contend—then clears and processes the current version head’s dependency set (proactively aborting stale readers), installs a new version node, and immediately releases the latch. Deltas are applied atomically without acquiring any latch, so concurrent delta commits on the same counter field never block each other. Stage 2 Improvements. The optimizer narrowed dependency invalidation from a full version-chain scan to only the current version head (reducing cost from 𝑂 (𝑉 ) to 𝑂 (1) per key, where 𝑉 is the key’s version-chain length), expanded the latch array from 128 to 1024 entries to reduce collision probability, and extended the commutative field set to cover order-ID counters, quantity, total, balance, and year-to-date fields.

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

holds write locks across validation and installation so no concurrent writer can intervene. Read/Write/Commit. Reads sample the version counter and value, cache the result as a versioned snapshot, and return without acquiring any lock. Bid-count, rating, and per-item-user counter writes accumulate a signed delta; all other writes buffer absolute values. Commit takes one of three paths: (1) read-only validates version snapshots with no locks acquired; (2) delta-only validates versions and applies deltas atomically without acquiring any write lock, making high-frequency counter transactions nearly contentionfree; (3) standard acquires write locks in sorted key order, validates, installs absolute writes, and applies deltas. Stage 2 Improvements. The optimizer fixed a type-handling bug in the read path that failed on certain numeric encodings and caused spurious aborts, normalizing all integer-valued fields to a common type; this repair simplified the write-key union computed at commit.

5.2.3 WGC – Workflow-Aware Graph Coloring. WGC transforms concurrency control from runtime conflict detection into pre-execution scheduling. Transactions are classified into three semantic colors: GREEN (read-only), YELLOW (writes that touch no status field), or RED (writes that change an item’s status). A pool of 128 singlethreaded Entity Execution Coordinators (EECs) partitions the entity space by hash. Each EEC enforces a color-compatibility matrix: multiple GREENs overlap freely; a single YELLOW may overlap with concurrent GREENs; REDs require the entity to be fully idle. Incompatible transactions are held in a hold-back queue and reevaluated after each completion. WGC is conflict-serializable, since transactions that conflict on an entity are dispatched to the same single-threaded EEC and run one at a time, while the color rules let only non-conflicting transactions overlap. Read/Write/Commit. Reads are client-side and non-blocking. Bidcount, rating, and per-item-user counter writes compute and buffer a signed delta; all other writes buffer an absolute value. At commit, the transaction’s color is determined (GREEN if no writes exist, RED if any write touches an item-status field, YELLOW otherwise), it is submitted to its EEC, and the caller blocks until the EEC applies the writes and signals completion. Stage 2 Improvements. The optimizer replaced an 𝑂 (𝑛) scan over active transactions in the compatibility check with three running per-color counts, and restructured the hold-back queue so that waiting transactions are re-evaluated in FIFO order after each completion. 5.2.4 PVL – Optimized Phased Validation Locking. PVL combines lock-free reads with a three-path commit strategy differentiated by write semantics. Each key carries a version counter. Reads record versioned snapshots; writes are classified as commutative deltas or standard absolute values, routing the commit to the lightest correct path for the transaction’s write footprint. PVL is conflictserializable, since every commit path validates that no version in the read snapshot has changed, and the standard path additionally 11

5.2.5 SAPL – State-Aware Phased Locking. SAPL combines pessimistic entity latching with OCC version validation in two layers. Transactions acquire shared or exclusive read/write latches on logical item entities throughout their lifetime, serializing statetransitioning operations. A version-validation layer at commit serves as a correctness backstop for remaining conflicts. Commutative counter updates are buffered as signed deltas and applied atomically at commit. SAPL is conflict-serializable through its two layers, with entity latches serializing state transitions on an item and commit-time version validation under sorted key locks aborting any transaction whose reads changed before its writes install. Read/Write/Commit. Reads to item-centric entity fields acquire a shared read latch with a non-blocking attempt that aborts on failure, and sample the version counter around the store fetch to detect torn reads. Bid-count, rating, and comment-counter writes accumulate a signed delta, while balance and year-to-date writes take the standard OCC path; item-status writes escalate the entity latch from shared to exclusive (with a version check between release and re-acquire to detect intervening modifications). Commit acquires per-key locks in sorted order, validates all read dependencies, installs absolute writes and deltas, and releases all locks and latches. Stage 2 Improvements. The optimizer moved balance and year-todate fields off the commutative delta path and back onto standard OCC validation, since treating their updates as blind commutative deltas violated per-record invariants; it also narrowed pessimistic latching to item records only and simplified how keys are mapped to entities.

6

Related Work

HakiCC builds on decades of theoretical and practical research on concurrency control protocols. There has been extensive research on distinct families of concurrency control protocols, each tailored to a specific hardware paradigm or workload. Two-Phase Locking (2PL) [5] enforces conflict ordering through lock acquisition; Optimistic Concurrency Control (OCC) [27] defers validation to commit time; Multi-Version Concurrency Control (MVCC) [4] maintains version histories for non-blocking reads; and Serializable Snapshot Isolation (SSI) [6] extends snapshot isolation to full serializability via anti-dependency tracking. Modern

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

Farzad Habibi, Juncheng Fang, and Faisal Nawab

in-memory systems such as Silo [54], Hekaton [30], TicToc [65], Cicada [32], and Bamboo [18] optimize these foundations for multicore hardware, while deterministic protocols such as Calvin [53] and BOHM [16] achieve predictable performance through preordered execution. Brook-2PL [19] targets high-contention hotspot workloads by statically analyzing a graph-based dependency structure (SLW-Graph) to enable deadlock-free lock acquisition and partial transaction chopping for early lock release. IC3 [58] similarly exploits static transaction analysis to reduce conflict footprint through fine-grained chopping. Each of these families excels under specific workload conditions but none adapts to a new workload without manual re-engineering.

SWE-agent [60] edits real codebases for automated software engineering, while multi-agent frameworks such as MetaGPT [20] and AutoGen [59] assign specialized roles to collaborating agents. These systems target general programming tasks and validate their output against unit tests, which cannot certify the correctness of a concurrency control protocol. HakiCC instantiates this agentic paradigm for CC protocol design, pairing specialized proposal and generation agents with a serializability verifier that enforces a formal correctness criterion in the loop. Evolutionary Optimization. Evolutionary programming is a classical approach to program synthesis that uses mutation and crossover operators to evolve a population of candidate programs [25, 29]. Evolutionary algorithms have been applied to regression [33, 44], automated algorithm and scientific discovery [9, 13], and scheduling [66]. However, these methods rely on handcrafted evolution operators that are difficult to design and may fail to capture domainspecific properties. Recent work has improved on this by replacing traditional operators with LLMs [2, 37, 43, 46]. FunSearch [43] pairs a pretrained LLM with a systematic evaluator in an evolutionary loop, allowing the LLM to propose program mutations guided by feedback. AlphaEvolve [37] extends this by enabling evolution over entire codebases, supporting multi-objective optimization, and using frontier LLMs as mutation engines. HakiCC builds on OpenEvolve [46], an open-source implementation of AlphaEvolve, to drive Stage 2 optimization of CC protocol implementations. Evolutionary optimization has recently been applied to systems research problems more broadly [10, 12, 15, 49]. Authors in [11] present case studies across cloud scheduling, load balancing, SQL query optimization, and transaction scheduling. They argue that the key challenge for AI in systems is problem formulation and strategic guidance rather than low-level implementation. HakiCC extends this direction to CC protocol design, applying LLM-driven evolutionary optimization with correctness and throughput as joint objectives.

Hybrid CC Protocols. Prior work has explored combining multiple concurrency control mechanisms to improve performance across varying workload conditions. Static and Dynamic OCC [63] switch from OCC to locking after the first retry. MOCC [57] and Hsync [45] propose hybrid 2PL–OCC protocols. ACC [51] goes further by adaptively selecting from a broader range of protocols at runtime. Tebaldi [48] groups transactions and assigns each group a different CC protocol. CormCC [50] proposes a more general framework by formalizing CC into four phases, allowing each operation to adopt any protocol’s policy as long as all protocols execute each phase in the same order. These approaches, however, are generally scoped to combinations of OCC and 2PL and require programmers to supply heuristics for choosing execution policies per operation. They are designed for dynamic workload adaptation rather than application-specific protocol design, and they do not exploit application-level transaction semantics. HakiCC differs by generating a complete, applicationspecific protocol implementation. Learned CC Protocols. The observation that a single protocol cannot satisfy all contention levels and workload patterns led to the development of learned concurrency control protocols. Polyjuice [56] models concurrency control as a dynamic policy table, defining the execution state as a high-dimensional combination of transaction type and data access patterns. The system searches a policy space of fine-grained actions to determine whether a transaction should wait, expose a speculative write, or abort. However, it does not support general transactions and treats all transactions accessing the same data uniformly, which can produce suboptimal decisions with high abort rates. NeurCC [39] advances this direction by modeling the CC mechanism as a continuous learnable function that maps dynamic database states directly to conflict-handling actions, coupled with Bayesian optimization and a graph reduction search algorithm. Both systems, however, generalize to a fixed action space across all workload types and do not account for application-specific semantics. HakiCC takes a fundamentally different approach. Rather than learning a policy over a predefined action space, it uses LLM agents to generate application-specific protocol implementations from scratch, producing protocols whose structure and semantics are tailored to the target application.

7

Conclusion

We presented HakiCC, a two-stage LLM-driven pipeline that automatically designs, verifies, and optimizes application-specific concurrency control protocols with minimal human intervention. Running HakiCC on TPC-C and AuctionMark produced ten protocols, all of which are verified for conflict-serializability after Stage 1, with Stage 2 improving the combined correctness-throughput score for nine out of ten protocols, yielding average throughput gains of +50.6% for TPC-C and +92.2% for AuctionMark. The ten generated protocols span multiple design families, including pessimistic, optimistic, versioned, deterministic, and semantic designs, confirming that application-conditioned generation produces structural diversity rather than converging on a single template. HakiCC establishes correctness empirically rather than by formal proof, and integrating formal verification while extending the pipeline to distributed protocols is a natural next step. HakiCC proves that LLM-driven agentic pipelines can serve as practical tools for CC protocol design, producing correct and competitive protocols across diverse OLTP workloads.

LLM-driven Agents. Large language models trained on code can generate executable programs from natural-language specifications [8], and recent work embeds them in agentic loops that reason, act, and repair their output under feedback [34, 47, 62]. 12

HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols

References

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

Learned from the Chameleon Testbed. In Proceedings of the 2020 USENIX Annual Technical Conference (USENIX ATC ’20). USENIX Association. [25] John R Koza. 1994. Genetic programming as a means for programming computers by natural selection. Statistics and computing 4, 2 (1994), 87–112. [26] Tim Kraska, Alex Beutel, Ed H Chi, Jeffrey Dean, and Neoklis Polyzotis. 2018. The case for learned index structures. In Proceedings of the 2018 international conference on management of data. 489–504. [27] Hsiang-Tsung Kung and John T Robinson. 1981. On optimistic methods for concurrency control. ACM Transactions on Database Systems (TODS) 6, 2 (1981), 213–226. [28] LangChain Inc. 2024. LangGraph: Building Stateful, Multi-Agent Workflows. https://github.com/langchain-ai/langgraph. [29] William B Langdon and Riccardo Poli. 2002. Foundations of genetic programming. Vol. 90. Springer. [30] Per-Åke Larson, Spyros Blanas, Cristian Diaconu, Craig Freedman, Jignesh M Patel, and Mike Zwilling. 2011. High-performance concurrency control mechanisms for main-memory databases. arXiv preprint arXiv:1201.0228 (2011). [31] Justin Levandoski, David Lomet, Sudipta Sengupta, Ryan Stutsman, and Rui Wang. 2015. Multi-version range concurrency control in deuteronomy. Proceedings of the VLDB Endowment 8, 13 (2015), 2146–2157. [32] Hyeontaek Lim, Michael Kaminsky, and David G Andersen. 2017. Cicada: Dependably fast multi-core in-memory transactions. In Proceedings of the 2017 ACM International Conference on Management of Data. 21–35. [33] He Ma, Arunachalam Narayanaswamy, Patrick Riley, and Li Li. 2022. Evolving symbolic density functionals. Science Advances 8, 36 (2022), eabq0279. [34] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Shashank Gupta, Bodhisattwa Prasad Majumder, Katherine Hermann, Sean Welleck, Amir Yazdanbakhsh, and Peter Clark. 2023. Self-Refine: Iterative Refinement with Self-Feedback. In Advances in Neural Information Processing Systems, Vol. 36. [35] Ryan Marcus, Parimarjan Negi, Hongzi Mao, Chi Zhang, Mohammad Alizadeh, Tim Kraska, Olga Papaemmanouil, and Nesime Tatbul. 2019. Neo: A learned query optimizer. arXiv preprint arXiv:1904.03711 (2019). [36] Jean-Baptiste Mouret and Jeff Clune. 2015. Illuminating search spaces by mapping elites. arXiv preprint arXiv:1504.04909 (2015). [37] Alexander Novikov, Ngân Vũ, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov, Borislav Kozlovskii, Francisco JR Ruiz, Abbas Mehrabian, et al. 2025. Alphaevolve: A coding agent for scientific and algorithmic discovery. arXiv preprint arXiv:2506.13131 (2025). [38] Patrick E. O’Neil. 1986. The Escrow Transactional Method. ACM Transactions on Database Systems 11, 4 (1986), 405–430. [39] Hexiang Pan, Shaofeng Cai, Tien Tuan Anh Dinh, Yuncheng Wu, Yeow Meng Chee, Gang Chen, and Beng Chin Ooi. 2026. Modeling Concurrency Control as a Learnable Function. Proceedings of the ACM on Management of Data 4, 3 (SIGMOD (2026), 1–28. [40] Christos H Papadimitriou. 1979. The serializability of concurrent database updates. Journal of the ACM (JACM) 26, 4 (1979), 631–653. [41] Guna Prasaad, Alvin Cheung, and Dan Suciu. 2020. Handling highly contended OLTP workloads using fast dynamic partitioning. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. 527–542. [42] Kun Ren, Jose M Faleiro, and Daniel J Abadi. 2016. Design principles for scaling multi-core oltp under high contention. In Proceedings of the 2016 International Conference on Management of Data. 1583–1598. [43] Bernardino Romera-Paredes, Mohammadamin Barekatain, Alexander Novikov, Matej Balog, M Pawan Kumar, Emilien Dupont, Francisco JR Ruiz, Jordan S Ellenberg, Pengming Wang, Omar Fawzi, et al. 2024. Mathematical discoveries from program search with large language models. Nature 625, 7995 (2024), 468–475. [44] Michael Schmidt and Hod Lipson. 2009. Distilling free-form natural laws from experimental data. science 324, 5923 (2009), 81–85. [45] Zechao Shang, Feifei Li, Jeffrey Xu Yu, Zhiwei Zhang, and Hong Cheng. 2016. Graph analytics through fine-grained parallelism. In Proceedings of the 2016 International Conference on Management of Data. 463–478. [46] Asankhaya Sharma. 2025. OpenEvolve: an open-source evolutionary coding agent. https://github.com/algorithmicsuperintelligence/openevolve [47] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language Agents with Verbal Reinforcement Learning. In Advances in Neural Information Processing Systems, Vol. 36. [48] Chunzhi Su, Natacha Crooks, Cong Ding, Lorenzo Alvisi, and Chao Xie. 2017. Bringing modular concurrency control to the next level. In Proceedings of the 2017 ACM International Conference on Management of Data. 283–297. [49] Jacopo Tagliabue. 2025. AI for Distributed Systems Design: Scalable Cloud Optimization Through Repeated LLMs Sampling And Simulators. arXiv preprint arXiv:2510.18897 (2025). [50] Dixin Tang and Aaron J Elmore. 2018. Toward coordination-free and reconfigurable mixed concurrency control. In 2018 USENIX Annual Technical Conference (USENIX ATC 18). 809–822.

[1] Anthropic. 2025. Claude Code: Agentic Coding in the Terminal. https://www. anthropic.com/claude-code. [2] Henrique Assumpção, Diego Ferreira, Leandro Campos, and Fabricio Murai. 2025. Codeevolve: An open source evolutionary coding agent for algorithm discovery and optimization. arXiv preprint arXiv:2510.14150 (2025). [3] Philip A. Bernstein and Nathan Goodman. 1980. Timestamp-Based Algorithms for Concurrency Control in Distributed Database Systems. In Proceedings of the International Conference on Very Large Data Bases (VLDB). 285–300. [4] Philip A Bernstein and Nathan Goodman. 1983. Multiversion concurrency control—theory and algorithms. ACM Transactions on Database Systems (TODS) 8, 4 (1983), 465–483. [5] Philip A Bernstein, Vassos Hadzilacos, Nathan Goodman, et al. 1987. Concurrency control and recovery in database systems. Vol. 370. Addison-wesley Reading. [6] Michael J Cahill, Uwe Röhm, and Alan D Fekete. 2008. Serializable Isolation for Snapshot Databases. In Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data. 729–738. https://doi.org/10.1145/1376616. 1376690 [7] Harrison Chase. 2022. LangChain. https://github.com/langchain-ai/langchain. [8] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating Large Language Models Trained on Code. arXiv preprint arXiv:2107.03374 (2021). [9] Xiangning Chen, Chen Liang, Da Huang, Esteban Real, Kaiyuan Wang, Hieu Pham, Xuanyi Dong, Thang Luong, Cho-Jui Hsieh, Yifeng Lu, et al. 2023. Symbolic discovery of optimization algorithms. Advances in neural information processing systems 36 (2023), 49205–49233. [10] Audrey Cheng, Shu Liu, Melissa Pan, Zhifei Li, Shubham Agarwal, Mert Cemri, Bowen Wang, Alexander Krentsel, Tian Xia, Jongseok Park, et al. 2025. Let the Barbarians In: How AI Can Accelerate Systems Performance Research. arXiv preprint arXiv:2512.14806 (2025). [11] Audrey Cheng, Shu Liu, Melissa Pan, Zhifei Li, Bowen Wang, Alex Krentsel, Tian Xia, Mert Cemri, Jongseok Park, Shuo Yang, et al. 2025. Barbarians at the gate: How ai is upending systems research. arXiv preprint arXiv:2510.06189 (2025). [12] Audrey Cheng, Harald Ng, Aaron Kabcenell, Peter Bailis, Matei Zaharia, Lin Ma, Xiao Shi, and Ion Stoica. 2026. AI-Driven Research for Databases. arXiv preprint arXiv:2604.06566 (2026). [13] Miles Cranmer. 2023. Interpretable machine learning for science with PySR and SymbolicRegression. jl. arXiv preprint arXiv:2305.01582 (2023). [14] Djellel Eddine Difallah, Andrew Pavlo, Carlo Curino, and Philippe CudréMauroux. 2013. OLTP-Bench: An Extensible Testbed for Benchmarking Relational Databases. PVLDB 7, 4 (2013), 277–288. http://www.vldb.org/pvldb/vol7/p277difallah.pdf [15] Mehmet Hamza Erol, Xiangpeng Hao, Federico Bianchi, Ciro Greco, Jacopo Tagliabue, and James Zou. 2026. Making Databases Faster with LLM Evolutionary Sampling. arXiv preprint arXiv:2602.10387 (2026). [16] Jose M Faleiro and Daniel J Abadi. 2014. Rethinking serializable multiversion concurrency control. arXiv preprint arXiv:1412.2324 (2014). [17] Juncheng Fang, Farzad Habibi, Binbin Gu, and Faisal Nawab. 2026. ImmortalChopper: Real-Time and Resilient Distributed Transactions in the Edge-Cloud. In 2026 IEEE 42nd International Conference on Data Engineering (ICDE). IEEE, 2008–2020. [18] Zhihan Guo, Kan Wu, Cong Yan, and Xiangyao Yu. 2021. Releasing locks as early as you can: Reducing contention of hotspots by violating two-phase locking. In Proceedings of the 2021 International Conference on Management of Data. 658–670. [19] Farzad Habibi, Juncheng Fang, Tania Lorido-Botran, and Faisal Nawab. 2026. Brook-2PL: Tolerating High Contention Workloads with A Deadlock-Free TwoPhase Locking Protocol. Proceedings of the ACM on Management of Data (2026). https://doi.org/10.1145/3769767 [20] Sirui Hong, Mingchen Zhuge, Jiaqi Chen, Xiawu Zheng, Yuheng Cheng, Ceyao Zhang, Jinlin Wang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. 2024. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. In International Conference on Learning Representations (ICLR). [21] Paul Jaccard. 1912. The distribution of the flora in the alpine zone. New Phytologist 11, 2 (1912), 37–50. [22] Nathan Jay, Noga H Rotman, P Godfrey, Michael Schapira, and Aviv Tamar. 2018. Internet congestion control via deep reinforcement learning. arXiv preprint arXiv:1810.03259 (2018). [23] Robert Kallman, Hideaki Kimura, Jonathan Natkins, Andrew Pavlo, Alexander Rasin, Stanley Zdonik, Evan P. C. Jones, Samuel Madden, Michael Stonebraker, Yang Zhang, John Hugg, and Daniel J. Abadi. 2008. H-Store: A High-Performance, Distributed Main Memory Transaction Processing System. Proceedings of the VLDB Endowment 1, 2 (2008), 1496–1499. [24] Kate Keahey, Jason Anderson, Zhuo Zhen, Pierre Riteau, Paul Ruth, Dan Stanzione, Mert Cevik, Jacob Colleran, Haryadi S. Gunawi, Cody Hammock, Joe Mambretti, Alexander Barnes, François Halbach, Alex Rocha, and Joe Stubbs. 2020. Lessons 13

SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA

Farzad Habibi, Juncheng Fang, and Faisal Nawab

[51] Dixin Tang, Hao Jiang, and Aaron J Elmore. 2017. Adaptive Concurrency Control: Despite the Looking Glass, One Concurrency Control Does Not Fit All.. In CIDR, Vol. 2. 1. [52] The Transaction Processing Council. 2007. TPC-C Benchmark (Revision 5.9.0). [53] Alexander Thomson, Thaddeus Diamond, Shu-Chun Weng, Kun Ren, Philip Shao, and Daniel J Abadi. 2012. Calvin: fast distributed transactions for partitioned database systems. In Proceedings of the 2012 ACM SIGMOD international conference on management of data. 1–12. [54] Stephen Tu, Wenting Zheng, Eddie Kohler, Barbara Liskov, and Samuel Madden. 2013. Speedy transactions in multicore in-memory databases. In Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. 18–32. [55] Dana Van Aken, Andrew Pavlo, Geoffrey J Gordon, and Bohan Zhang. 2017. Automatic database management system tuning through large-scale machine learning. In Proceedings of the 2017 ACM international conference on management of data. 1009–1024. [56] Jiachen Wang, Ding Ding, Huan Wang, Conrad Christensen, Zhaoguo Wang, Haibo Chen, and Jinyang Li. 2021. Polyjuice: { High-Performance } transactions via learned concurrency control. In 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI 21). 198–216. [57] Tianzheng Wang and Hideaki Kimura. 2016. Mostly-optimistic concurrency control for highly contended dynamic workloads on a thousand cores. Proceedings of the VLDB Endowment 10, 2 (2016), 49–60. [58] Zhaoguo Wang, Shuai Mu, Yang Cui, Han Yi, Haibo Chen, and Jinyang Li. 2016. Scaling multicore databases via constrained parallel execution. In Proceedings of the 2016 International Conference on Management of Data. 1643–1658. [59] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah,

Ryen W White, Doug Burger, and Chi Wang. 2023. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv preprint arXiv:2308.08155 (2023). [60] John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. In Advances in Neural Information Processing Systems, Vol. 37. [61] Zongheng Yang, Wei-Lin Chiang, Sifei Luan, Gautam Mittal, Michael Luo, and Ion Stoica. 2022. Balsa: Learning a query optimizer without expert demonstrations. In Proceedings of the 2022 International Conference on Management of Data. 931–944. [62] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In International Conference on Learning Representations (ICLR). [63] Philip S. Yu and Daniel M. Dias. 1992. Analysis of hybrid concurrency control schemes for a high data contention environment. IEEE Transactions on Software Engineering 18, 2 (1992), 118. [64] Xiangyao Yu, George Bezerra, Andrew Pavlo, Srinivas Devadas, and Michael Stonebraker. 2014. Staring into the abyss: An evaluation of concurrency control with one thousand cores. (2014). [65] Xiangyao Yu, Andrew Pavlo, Daniel Sanchez, and Srinivas Devadas. 2016. TicToc: Time Traveling Optimistic Concurrency Control. In Proceedings of the 2016 International Conference on Management of Data. https://doi.org/10.1145/2882903. 2882935 [66] Fangfang Zhang, Su Nguyen, Yi Mei, and Mengjie Zhang. 2021. Genetic Programming for Production Scheduling. Springer.

14

Related documents

• HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols#1155824
• Communication and Verification in LLM Agents towards Collaboration under Information Asymmetry#1013459
• RPA-Check: A Multi-Stage Automated Framework for Evaluating Dynamic LLM-based Role-Playing Agents#10399
• Ignorance or Incompetence? Constructing Knowledge-Gated, Verifiable Tasks for LLM Agents#799534
• Ignorance or Incompetence? Constructing Knowledge-Gated, Verifiable Tasks for LLM Agents#798111