Jailbreak: LLM-Generated Storage Readers Bypass Database Engines for 27x Analytics Speedup

Paper: 2607.07696 Authors: Victor Giannakouris, Immanuel Trummer Categories: cs.DB, cs.AI

The Gap

If you’re running analytical queries on data that lives inside an external database—say PostgreSQL or MySQL—you’re funneled through JDBC or ODBC drivers. These drivers were designed for transactional workloads: parse SQL, plan a query, execute it row by row, serialize results, deserialize on the client side. For bulk columnar analytics, this pipeline is a bottleneck you didn’t choose but can’t avoid. Prior work has tried to optimize within this constraint: query pushdown, connector improvements (like the Spark JDBC connector’s partition parallelism), or specialized analytical engines like DuckDB that sit outside the database but still read through the driver. Nobody has seriously asked: what if we skip the driver entirely and read the storage files ourselves?

The reason nobody tried is obvious: database file formats are notoriously complex and poorly documented. PostgreSQL’s heap format, MySQL’s InnoDB page structure—these are implementation artifacts, not specs handed out at conferences. Writing parsers by hand is a months-long engineering effort per format, and any schema change or version update breaks your code. The gap is real: we know direct file access would be faster, but the engineering cost of building and maintaining readers is prohibitive.

This paper’s logical path:

Problem: JDBC/ODBC forces bulk reads through transactional pipeline
    |
    v
Observation: File formats are complex but fully specified in source code + docs
    |
    v
Assumption: LLMs can ingest source code and docs to generate correct parsers
    |
    v
Method: LLM-assisted code synthesis produces direct storage readers
    |
    v
Evidence: TPC-H correctness verified, up to 27x throughput improvement
    |
    v
Conclusion: LLM-generated readers are viable, generalizable, and fast

The Increment

One sentence: Before this paper, bypassing the database engine for direct file access required months of manual parser engineering per format; after this paper, an LLM can generate a correct, high-performance reader from documentation alone in minutes.

Core Mechanism

Jailbreak has three stages. First, it collects the “blueprint” for a database’s storage format: source code files (like PostgreSQL’s heapam.c or MySQL’s page0page.cc), official documentation, and any supplementary specs. These artifacts are fed into an LLM with a carefully structured prompt that asks for a complete table-scanning reader. The LLM doesn’t just output a spec—it outputs runnable code.

Second, the generated reader is compiled and executed against actual storage files (.mdf, .ibd, heap files, etc.). The reader parses pages, interprets tuple headers, handles null bitmaps, reconstructs column values, and materializes everything into Apache Arrow columnar buffers. Arrow is the lingua franca of modern analytical engines, so the output plugs directly into DuckDB, Spark, cuDF, or Spark RAPIDS without further transformation.

Third, correctness and performance are validated. Jailbreak compares query results from its direct readers against JDBC/ODBC baselines on the full TPC-H benchmark—not just row counts, but every cell of every result set must match. Performance is measured end-to-end: time from storage file to analytical result.

Stage 1: LLM Code Synthesis
+-------------------+     +-------------------+
| Database source   |     | Database docs     |
| code (.c files)   |     | (spec, wiki)      |
+-------------------+     +-------------------+
         \                       /
          \                     /
           v                   v
        +-----------------------+
        |       LLM            |
        | (code generation     |
        |  with structured     |
        |  prompting)          |
        +-----------------------+
                |
                v
        +-----------------------+
        | Generated storage    |
        | reader (C/Rust code) |
        +-----------------------+

Stage 2: Direct File Reading
+-------------------+     +-------------------+
| PostgreSQL heap   |     | MySQL InnoDB      |
| files             |     | .ibd files        |
+-------------------+     +-------------------+
         \                       /
          v                     v
        +-----------------------+
        | Generated reader     |
        | (parses pages,       |
        |  tuples, headers)    |
        +-----------------------+
                |
                v
        +-----------------------+
        | Apache Arrow         |
        | columnar buffers     |
        +-----------------------+
                |
                v
        +-----------------------+
        | DuckDB / Spark /     |
        | cuDF / RAPIDS        |
        +-----------------------+

Structural Metaphor

Think of a locked warehouse where all your data is stored on shelves. The only official entrance is a single service window (JDBC/ODBC) with a clerk who must: take your written request (SQL), walk to the shelf, pick up one item, carry it back, hand it to you through the window, then repeat. Fine for grabbing a few boxes. Disastrous when you need the entire inventory.

Previous approaches tried to make the clerk faster—add more windows, give the clerk a cart, let the clerk delegate to assistants inside. But the fundamental constraint remains: everything goes through the window.

Jailbreak does something different. It hires a specialist locksmith (the LLM) and hands them the warehouse’s blueprints—the architectural drawings and construction manuals (source code and documentation). The locksmith studies these blueprints, then cuts a custom key (the generated reader) that opens the warehouse’s loading dock directly. Now you can drive a truck in and load pallets (Arrow columnar buffers) straight off the shelves.

The key insight: you don’t need a universal lock-picking kit. You just need someone who can read this specific warehouse’s blueprints. And LLMs happen to be very good at reading blueprints—if you hand them the right ones.

The metaphor is load-bearing because each part maps precisely:

• Warehouse blueprints = database source code + docs
• Locksmith = LLM
• Custom key = generated storage reader
• Loading dock = direct file I/O
• Pallets = Arrow columnar buffers
• Service window = JDBC/ODBC bottleneck

Key Concepts

• Columnar Buffers (Apache Arrow): Imagine you have a spreadsheet with columns: Name, Age, City. Row-oriented storage (how databases store things on disk) keeps each person’s data together: [Alice, 30, NYC], [Bob, 25, LA]. Column-oriented storage keeps each *attribute together: [Alice, Bob, …], [30, 25, …], [NYC, LA, …]. Why does this matter? When you’re computing “average age,” you only need the Age column. Columnar storage means you read exactly what you need, nothing else—and modern CPUs love this because sequential data fits in cache. Apache Arrow is the standard in-memory columnar format that almost every analytical engine understands, so once your data is in Arrow, it can flow directly to DuckDB, Spark, or GPU frameworks without copying or conversion.

• LLM-Assisted Code Synthesis: This isn’t “ChatGPT, write me a database parser.” The method is structured: the LLM receives specific source files (not a vague prompt), is guided to produce compilable code (not pseudocode), and the output is verified against known-correct results. Think of it as the LLM acting as a translator between human-readable documentation and machine-executable parsing logic. The “assisted” part matters—there’s prompt engineering, validation, and likely iterative refinement. The contribution is showing that this translation pipeline is practical for a class of problems (storage format parsing) that previously required deep domain expertise.

• Database Lock-in: When your data lives inside a PostgreSQL database, you can only access it through PostgreSQL’s interfaces. Even if you want to run Spark or DuckDB queries on that data, you have to go through PostgreSQL’s driver. This “lock-in” isn’t a feature—it’s an architectural accident. Your data is trapped behind an interface designed for a different purpose (transactional queries, not bulk analytics). Jailbreak’s thesis is that this lock-in is artificial: the data sits in files you could read directly, if only you knew how to decode the format.

Framework Shift

Before (mainstream approach):
                                          +------------------+
+----------+    +----------+    +-------->| Query Engine     |
| App/ETL  |--->| JDBC/    |--->| DB      | (parses, plans,  |
|          |    | ODBC     |    | Server  |  executes,       |
+----------+    +----------+    +-------->|  serializes)     |
                                          +------------------+
                                                    |
                                                    v
                                          +------------------+
                                          | Results via      |
                                          | driver (rows)    |
                                          +------------------+

After (this paper):
                                          +------------------+
+----------+    +---------------------+   | Storage files    |
| App/ETL  |--->| LLM-generated       |<--| (.mdf, .ibd,     |
|          |    | direct reader       |   |  heap files)     |
+----------+    +---------------------+   +------------------+
                         |
                         v
               +---------------------+
               | Apache Arrow        |
               | columnar buffers    |
               +---------------------+
                         |
                         v
               +---------------------+
               | DuckDB / Spark /    |
               | cuDF / RAPIDS       |
               +---------------------+

From forcing every read through a transactional query engine to reading storage files directly into analytical buffers, the core shift is treating the database’s physical storage as a first-class data source rather than an implementation detail hidden behind a driver.

Expert Assessment

Problem choice: This is a genuine gap. The tension between OLTP-designed database interfaces and OLAP workloads is real and widely felt—anyone running analytics on operational databases knows the pain. The paper situates itself well: prior work optimized within the driver paradigm (better connectors, query pushdown), while this paper asks whether the paradigm itself is necessary. It’s a natural question that surprisingly few have pursued, likely because the manual engineering cost was prohibitive. The read-replica / offline-pipeline framing is practical and realistic.

Method maturity: The core insight—LLMs can read source code to regenerate parsers—is clever and genuinely novel. It transforms a software engineering problem (months of manual parsing code) into an inference problem. However, the approach has a fragility that the paper doesn’t fully address: what happens when the LLM generates code that compiles and runs but produces subtly incorrect results for edge cases (corrupted pages, unusual null patterns, TOAST’d values in PostgreSQL)? The TPC-H validation is a good start, but TPC-H uses clean, well-structured data. Real-world databases have messy corners—partially written pages, vacuumed tuples, encoding edge cases.

There’s also a dependency on the quality and completeness of the source code/docs provided to the LLM. For PostgreSQL, which is open-source and well-documented, this works well. For proprietary or poorly documented formats, the approach may struggle. The paper acknowledges this but doesn’t quantify it.

Experimental integrity: The baselines are fair in principle—JDBC/ODBC is the actual production alternative for most users. But a stronger comparison would include optimized analytical connectors (like pg_bulkload, or direct COPY-based pipelines) rather than just vanilla JDBC. The 27x number is impressive but likely varies significantly with table size, column count, and network topology. The TPC-H correctness check is rigorous: verifying every cell of every query result is the right standard. One concern: the paper evaluates on analytical snapshot scenarios (read replicas, offline pipelines), which is the right framing, but readers should be careful not to generalize to transactional or incremental-read scenarios.

Writing quality: The abstract is crisp and well-structured. The motivation section does its job. Where the paper could improve: the LLM prompting methodology deserves more space. What exactly is in the prompt? How many iterations? What’s the failure rate on first attempt? These details matter enormously for reproducibility and for understanding the approach’s true cost. The evaluation section would also benefit from an ablation: how much of the speedup comes from bypassing the query engine vs. the columnar format vs. removing serialization overhead?

Verdict: weak accept — The idea is genuinely creative, the results are strong, and the problem is real. The main weakness is insufficient depth on failure modes, LLM prompting details, and comparison against optimized (not just vanilla) baselines. With those additions, this could be a strong accept.

Takeaways

1. LLM-as-format-translator is a transferable pattern. The core idea—feed an LLM the source code and docs for an opaque format, ask it to generate a reader—applies far beyond databases. Think: proprietary log formats, binary sensor data, legacy file formats from acquired companies. If you can find the documentation, you can potentially generate a parser.

2. Apache Arrow as the universal “pallet format” is validated again. This paper’s architecture only works because Arrow is a lingua franca. If you’re designing data pipelines, standardizing on Arrow as your interchange format is increasingly non-negotiable.

3. The bottleneck you accept is often architectural, not algorithmic. The 27x speedup doesn’t come from a better algorithm—it comes from removing layers that were never designed for your workload. Before optimizing within a paradigm, ask: is the paradigm itself the bottleneck?

4. “Can the LLM do this?” is becoming a valid research question for systems problems. This paper is part of a growing trend: using LLMs not as end-user tools but as components in systems that automate traditionally manual engineering tasks. If you’re building tools, consider where LLM code generation could replace boilerplate or domain-specific parsing logic.