Oasis: Hiding the Cost of Querying Parquet Files in the Datapath

Oasis: Hiding the Cost of Querying Parquet Files in the Datapath Luca Tagliavini∗

Gustavo Alonso

ETH Zürich Zürich, Switzerland jonas.dann@inf.ethz.ch

Apple Zürich, Switzerland l_tagliavini@apple.com

ETH Zürich Zürich, Switzerland alonso@inf.ethz.ch

arXiv:2608.02268v1 [cs.DB] 3 Aug 2026

Abstract Cloud-native database systems disaggregate compute and storage resources to improve cost efficiency over traditional monolithic architectures through elasticity and resource pooling. Studies of production data warehouse workloads show that scans (including round trips to storage) account for roughly half of total query runtime. Data lakes and lakehouses amplify this bottleneck through per-query decoding of storage-optimized, compressed file formats such as Parquet. As storage and network bandwidth continue to outpace CPU cost-performance, the CPU cycles spent on decoding increasingly undermine the cloud’s cost-efficiency promise. This has led to a wave of specialization across the stack with custom hardware at cloud-vendor scale at the extreme end. We build on this trend and present Oasis, a data-processing SmartNIC that offloads Parquet decoding into the network datapath as a custom hardware accelerator. Oasis features a hardware decoder architecture, software abstraction layer, and end-to-end integration with DuckDB. Our evaluation shows that Oasis hides the cost of Parquet decoding behind the network datapath with minimal overhead, overlapping the scan with the remainder of the query execution. In the best case, this almost doubles DuckDB query throughput. PVLDB Reference Format: Jonas Dann, Luca Tagliavini, and Gustavo Alonso. Oasis: Hiding the Cost of Querying Parquet Files in the Datapath. PVLDB, 14(1): XXX-XXX, 2020. doi:XX.XX/XXX.XX PVLDB Artifact Availability: The source code, data, and/or other artifacts have been made available at https://github.com/celeris-labs/oasis.

1

Introduction

Cloud-native database systems have improved upon traditional, monolithic database architectures by disaggregating storage and compute, improving cost efficiency through elasticity and resource pooling. However, disaggregated architectures introduce their own challenges around data movement from cloud object storage to compute nodes. Recent studies of production data warehouse workloads show that scanning data alone accounts for roughly half of total query runtime [46, 47], rising to over 80% for read-only queries [48]. In data lakes and lakehouses [53], which process queries directly on raw input files, this bottleneck is amplified by per-query decoding ∗ Work was done while the author was a student at ETH Zürich.

This work is licensed under the Creative Commons BY-NC-ND 4.0 International License. Visit https://creativecommons.org/licenses/by-nc-nd/4.0/ to view a copy of this license. For any use beyond those covered by this license, obtain permission by emailing info@vldb.org. Copyright is held by the owner/author(s). Publication rights licensed to the VLDB Endowment. Proceedings of the VLDB Endowment, Vol. 14, No. 1 ISSN 2150-8097. doi:XX.XX/XXX.XX

TPC-H throughput (Q/h)

Jonas Dann

In-memory 10000 7500 5000 2500 0

Parquet files 45%

1

4

8

12 16 20 24 DuckDB worker threads

28

32

Figure 1: TPC-H (scale factor 30, four streams) throughput benchmark in queries per hour using DuckDB on pre-loaded data in memory vs on Parquet files across 1–32 DuckDB worker threads. Data decoding makes up almost half of the query runtime when querying Parquet files directly.

of encoded and compressed file formats such as Parquet [4], which are optimized for storage rather than scan performance. To quantify this effect, Figure 1 shows that decoding Parquet files nearly halves DuckDB’s [41] query throughput compared to processing data in DuckDB’s in-memory format. This decoding tax is fundamentally a compute problem: every query pays it in CPU cycles, regardless of how fast the underlying storage delivers the data. As storage and network bandwidths have increased by orders of magnitude over the last decade, the bottleneck for data processing in the cloud has shifted to the CPUs [19, 29, 49, 54]. Specifically, the stagnant cost-performance of CPUs undermines the cost-efficiency promise of the cloud. Enabled by the scale of the cloud, these economics have triggered a wave of specialization across the whole stack, from compiled query engines [25, 36] through unikernels at the operating-system level [28, 32] to GPU query processing [21] and custom accelerators [14, 24] at the hardware level. The common thread is specialization that reduces the overhead introduced by general abstractions (such as general-purpose CPUs). In the case of Parquet decoding, dedicated accelerator prototypes [31, 40] have demonstrated the potential for hardware specialization. However, these accelerators lack a clear deployment path, do not cover the subset of the Parquet standard used in practice, and are isolated efforts without end-to-end integration into a database system. SmartNICs, which co-locate user-accessible processing capabilities with the network interface controller (NIC), offer precisely such a deployment path: they can process data directly in the network datapath from object storage to compute [26]. Cloud providers already deploy SmartNICs at massive scale: for over a decade, Microsoft Azure has equipped all new servers with FPGA-based SmartNICs to offload the overhead of tasks such as network virtualization [14]. Similarly, AWS Nitro [3] and Alibaba CIPU [2] offload virtualization, storage access, and security functions across their

Parquet file

Dictionary page

Bit RLE run width Header Repeated value (1B)

Page header

Run header (varint), LSB selects the run type:

...

Column chunk

Page header

Data page

Run length 0

...

Run length 1

... Metadata footer Types

encoding, and hybrid run-length (RLE)/bit-packing (BPE) encoding. Thus, there are two page types: data pages and dictionary pages. Dictionary encoding. A dictionary page written at the start of the column chunk records the distinct values of the column, and subsequent data pages store indices into that dictionary rather than the values themselves. This is very effective for low-cardinality columns since the resulting indices into the dictionary are dense and thus occupy only a small value range that can be represented by a much smaller number of bits than the original data. In practice, DuckDB encodes columns with a dictionary until the dictionary grows too large, exceeding around 1 MiB, and then falls back to plain encoding for the remainder of the data. Hybrid RLE/BPE. The indices produced by dictionary encoding are then encoded as hybrid RLE/BPE pages. The scheme interleaves RLE and BPE runs, choosing whichever representation is more compact for a given run of values. Each run is prefixed by a variable-length integer (varint) header whose least-significant bit selects the run type. If the bit is clear, the run is run-length encoded: the remaining header bits give the repetition count, and the payload stores the repeated value, using ⌈bit width/8⌉ bytes. If the bit is set, the run is bit-packed: the remaining header bits give the run length in groups of eight values, and the payload stores the values back-to-back at a fixed bit width, least-significant bits first. Notably, the bit width itself is not encoded in the run headers but is derived from the dictionary size and written as a single byte preceding the stream of indices. When writing Parquet files, DuckDB commits to an RLE run once four or more consecutive values are equal. Otherwise, it accumulates values into bit-packed blocks of 256 values. Metadata. Parquet stores metadata at three levels. At the page level, each data page is preceded by a page header recording the page type, the number of values, byte length, and encoding information. Each page also optionally has Dremel-style [33] definition and repetition levels that track nullability and nested structures, respectively. At the column chunk level, the column metadata records the column’s type, the byte offsets of the first data page and the optional dictionary page, value and null counts, and optional min/max statistics. The compression scheme is also defined per column chunk. At the file level, a footer at the end of the file contains the complete file metadata: the schema, the number of rows, and the row-group and column-chunk metadata for every column chunk. The footer length is stored in the last bytes of the file and must be read first.

Hybrid RLE/BPE encoded data page Bit-packed run Header

...

Row group (122,880 rows)

Values

→ RLE: value repeated <length> times → BPE: <length> groups of 8 values

Bit-packed values, e.g., bit width 3: Byte 0 v0

v1

Byte 1 v2

v3

v4

Byte 2 v5

v6

v7

Row group stats

Figure 2: Parquet compressed, columnar file format horizontally partitioning data into row groups and details on hybrid run-length/bit-packing encoding for data pages.

respective fleets. While these deployments target cloud infrastructure, the same hardware is now being enabled for database systems: Microsoft Fabric has recently begun targeting FPGAs for query execution [21]. Inspired by this, we propose Oasis, a data-processing SmartNIC for cloud-native database systems that offloads line-rate Parquet decoding into the network datapath and integrates endto-end as a DuckDB extension. For the custom hardware design backing Oasis, we doubled the decompression throughput of a popular Snappy decompression core and designed a hardware decoder pipeline that can reach line-rate decoding in many cases. Our experimental results show that we can completely hide the cost of decoding Parquet files behind the network datapath of the database system with minimal overhead. Our key contributions are: (C1) Oasis SmartNIC architecture (Section 3) that sits on the network datapath of the compute node and hosts a set of hardware Parquet decoders (Section 4). (C2) Software abstraction layer for Oasis, handling softwareside output buffer management, decoder configuration, and scheduling of jobs to hardware decoders (Section 5.1). (C3) DuckDB extension with end-to-end integration of Oasis into the DuckDB database system (Section 5.2).

2

Background

In this section, we introduce Parquet and its encodings, Snappy, and hardware design considerations for on-datapath SmartNICs.

2.2 2.1

Parquet File Format

Snappy Compression Scheme

Snappy [17] is a dictionary-based compression scheme that prioritizes decompression speed over compression ratio. A Snappycompressed page begins with a preamble encoding the uncompressed length as a varint, followed by a sequence of elements of two kinds: literals, which copy raw bytes from the compressed stream to the output, and copies, which duplicate a run of bytes that appeared at an offset in the already-decompressed output. Each element starts with a tag byte whose two least-significant bits identify the element type: 00 denotes a literal, while 01, 10, and 11 denote copies with one-, two-, and four-byte offsets, respectively. For literals, the remaining six bits of the tag byte encode lengths of up to 60 bytes directly. Longer lengths are stored in up to four additional bytes following the tag. Copies with a one-byte offset

Apache Parquet [4] is an open-source columnar file format designed for efficient, compressed storage of tabular data. Figure 2 shows the structure of a Parquet file. At the top level, the file is divided horizontally into one or more row groups, each containing a contiguous subset of the table’s rows (for example, rows 0–122,879 under the default row group size of the DuckDB Parquet writer). Within each row group, the data of each column is stored as a column chunk, which is in turn divided into pages. Parquet compresses data in two steps: page data is first encoded, and then a general-purpose compression scheme, such as Snappy, is applied to each page of a column chunk independently. There are several different encodings, but the three used in practice [31] are plain encoding, dictionary 2

Parquet column chunk

Oasis SmartNIC Memory-mapped configuration

Column-chunk metadata

Page-header parser

Column-chunk decoder Bypass stream

TLB

Virtualization

Snappy decompressor

Dict

Data center network

Cloud object storage Parquet file

Column-chunk decoder

Data fetcher

Column-chunk decoder

Network stack QSFP

Output writer

PCIe

DMA controller

Main memory

Column-chunk decoder

Output buffer

Database system

Profiler Bypass

State machine

Page-type multiplexer Encoded Plain RLE/BPE run decoder Strip definition Type-aware dictionary

levels

Stream normalizer Decoded column

Figure 3: Oasis SmartNIC architecture and detailed hardware column-chunk decoder pipeline.

3

encode lengths of 4–11 bytes and offsets of up to 2,047 bytes, packing three offset bits into the tag byte, whereas copies with two- and four-byte offsets encode lengths of up to 64 bytes with the offset stored in the subsequent bytes. The compressor processes its input in blocks of 64 KiB, so copy offsets never exceed this distance and the working set of the decompressor remains small.

2.3

Oasis SmartNIC: Overview

Oasis is an on-datapath SmartNIC that sits on the network datapath of the compute node in a disaggregated architecture with direct connections to the network through its own network port on one side and to the main memory of the host system through PCIe on the other side. Data that the database system fetches from cloud object storage always flows through the Oasis SmartNIC. Figure 3 shows the Oasis architecture, with 𝑛 column-chunk decoders at its heart, each decoding one column chunk of a Parquet file at a time. The figure also shows a detailed datapath of the hardware columnchunk decoder pipelines that we discuss in Section 4. Integration with the database system is discussed in Section 5. The Oasis SmartNIC is controlled by the database system through a memory-mapped configuration that can be read and written from the host CPU. The high-level datapath is made up of a network stack handling the network protocol-level details of fetching data from a remote storage server, a data fetcher that instructs the network stack to fetch data based on configurations written through the memorymapped interface, a set of column-chunk decoder pipelines, an output writer that coalesces data from the column-chunk decoders and generates memory requests to write the data to main memory, and a direct-memory access (DMA) controller that handles the details of writing data through PCIe to main memory. There is also a bypass stream that we use to fetch metadata and string columns, which we currently do not handle in hardware and instead decode on the CPU. Beyond the datapath, profiling logic sitting on the output streams counts clock cycles of the data flow, a translation lookaside buffer (TLB) performs address translations from virtual to physical addresses, and further virtualization components support multiple parallel streams, interrupts, and related functionality. The key property of this architecture is that data is decoded as it streams into the database system: a column chunk is decompressed and decoded while it streams from the network port to host memory, rather than being written to memory in its encoded form first and then read back by the CPU and decoded. Communication and decoding overlap at cache-line (64 bytes) granularity. Oasis further exploits the parallelism the Parquet format inherently offers: column chunks are self-contained units carrying their own metadata and dictionary, so the data fetcher can hand independent column chunks to the 𝑛 instantiated column-chunk decoders without any synchronization between them. Three benefits follow. First, we

SmartNIC Hardware Design Considerations

SmartNICs are widely deployed in the cloud [14] and have become an established target for offloading data-intensive processing [12, 16]. We prototype our Oasis SmartNIC on a network-enabled fieldprogrammable gate array (FPGA). FPGAs map custom digital circuit designs (a set of logic gates and their connections) to a grid of resources (e. g., look-up tables, registers, and SRAM) connected with a programmable interconnection network. Synthesizing a design for such an architecture involves assigning the logic gates and other structures to their physical equivalents on the chip (place) and allocating interconnect wires for their connections (route). Unlike in instruction-based processors (CPUs and GPUs), the performance of a hardware design is not limited by the number of instructions that can be executed in each clock cycle but by (i) how efficiently the available hardware resources can be utilized to exploit data and pipeline parallelism and (ii) the achievable clock frequency of the design. Specifically, the achievable clock frequency is restricted by the longest path (measured in nanoseconds) between two registers, which we call the critical path. The critical path needs to fit inside one clock cycle (e. g., 1/250 MHz = 4 ns). The path length is given by the sum of signal propagation delays on the path and the time that the gates on the path need to stabilize their output after a signal arrives at their input. In complex hardware designs, the number of logic gates in the paths and the fan-out of signals limit the clock frequency. Less often, the general density of the design becomes the limiting factor for routing because it restricts freedom in placing the logic. To optimize clock frequency, we try to either restructure the hardware design from scratch or pull the logic apart with more pipelining, which, however, is not always possible (e. g., if there are tight feedback loops for backpressure). The performance of the design is linear in the clock frequency that the synthesis achieves. All of this leads to very different design principles for data processing in specialized hardware that we will explain in more detail when we apply them to our Oasis SmartNIC. 3

eliminate redundant copies of the encoded data. Second, the decoding overhead is lifted off the CPU entirely and can be fully hidden by overlapping query execution with decoding. Third, decoding throughput stops being bound by how many instructions we can execute on the CPU and is instead bound only by how efficiently we can build the decoding pipeline and by the network and interconnect speeds. The data that arrives in the output buffers is already decoded, in the representation that the database system expects, so no conversion step is left for the host and the handoff is zero-copy.

4

16 decoders Literal FIFO

Command Gen.

Data path

Long history

Data path 0

Dual decoder Command Gen. SH 0 LH 0

Data path 1

Ring buffer Select SH 1 LH 1

Fold

Hardware Column-chunk Decoder

Figure 4: Original 8 byte-wide Snappy decompressor and our optimized 16 byte-wide design with dual-issue copies.

best of our knowledge, is the fastest open-source core available. We apply two optimizations to the existing design to double its performance (cf. Figure 4). We first double the datapath width from 8 bytes to 16 bytes, allowing the design to both consume more input and emit more output in each clock cycle. As we will show in the microbenchmarks (Section 6.2.1), this alone doubles performance for literal-heavy (i. e., mostly uncompressed) input data that is piped through the decompression module directly. For copy-heavy (i. e., highly compressed) input data, however, the original design is severely limited by only decompressing a single copy command per clock cycle, which the wider datapath does not help with. Thus, we additionally extend the original design to decompress two copies per clock cycle. To handle decoding multiple copies per data beat, we duplicate the literal storage implemented as on-chip SRAM with two separate datapaths: one taken by the first copy command and one by the potential second copy command. This allows us to double copy throughput at the cost of doubling the resource utilization of that part of the datapath. The individual results of the two datapaths are folded into one unified output afterwards. Introducing the data parallelism of copy commands created a new issue with timing of the hardware design, however. It forces the design to find two copy commands in the input per clock cycle, which creates a long chain of varint decoders, doubling the length of the critical path of the design. We thus designed a two-entry ring buffer which holds pre-decoded varints that are decoded in a separate pipeline step before we actually select the two run headers for copy commands. This decouples the decoding and header extraction from the input data beat and relaxes timing of the critical path.

Page-header Parser

The first module in the pipeline is the page-header parser, which decodes Apache Thrift [45] encoded metadata that precedes every page in a column chunk. The page-header parser extracts the number of expected values that are encoded in the page, the page type (dictionary or data), the encoding used on the page (plain or hybrid RLE/BPE encoding + dictionary), and whether it is the last page in the column chunk. The last-page flag is used to flush the whole column-chunk decoder to reset it for the next column chunk. The page-header parser is implemented in two stages as a state machine based on the Thrift schema of Parquet page headers. In the first (slow) parsing stage, we decode the page header one encoded value at a time. The varint encoding used on most values in the Thrift schema makes it very hard to decode values in parallel. However, since the page header is a fraction of the data of a page, doing the header parsing iteratively instead of in parallel does not significantly impact performance. In the second (fast) payload stage, we then pipe through the remaining bytes of the page, which are the actual payload. The parsing stage uses a shift register that is shifted by one byte at a time (to reduce the multiplexer complexity) and one varint decoder placed at the first five bytes of that shift register. We also maintain a skip register. In each state of the state machine, if the skip register is 0, we decode a value. We set the value of the skip register to the length of the decoded varint and transition to the next state. We repeat this process until we reach the payload. In the payload stage, we first flush the remaining bytes from the shift register and then forward full data beats to the output.

4.2

Literal FIFO Short history

An Oasis hardware column-chunk decoder (right side of Figure 3) is a pipeline that extracts metadata from page headers, decompresses Snappy-compressed pages, and then decodes them. Dictionary pages are forwarded to the value port of a type-aware dictionary, hybrid RLE/BPE-encoded pages go through a run decoder and the lookup port of the dictionary, and plain pages pass through a bypass that strips the definition levels. The fully decoded values are then joined into one normalized stream that is written to a contiguous buffer. In the following, we describe the major components of the hardware column-chunk decoder pipeline.

4.1

Decoder

4.3

Hybrid RLE/BPE Run Decoder

The hybrid RLE/BPE run decoder strips off the definition levels, reads the bit width from the payload, and proceeds decoding the remaining stream of runs. The run decoder has a target line rate of 16 decoded values per clock cycle in the average case which means we have to retire one RLE run or 16 bit-packed values per clock cycle. Run payloads are not aligned to data beat boundaries, so the data needed to decode the current run may straddle two data beats. We derive a worst-case bound: the value of an RLE run needs at most ⌈bit width/8⌉ bytes (at most 4, since the specification caps the bit width at 32), and one BPE decoding step needs bit width · 𝑁 bytes, where 𝑁 is the number of output values per data beat divided by eight. Thus, storing the current data beat (64 bytes) plus one

Snappy Decompressor

Snappy decompression is the computationally heaviest operation in Parquet decoding and poses the most significant bottleneck in the column-chunk decoder. We base our Snappy decompressor on the existing decompression core VHSNUnzip1 , which, to the 1 https://github.com/abs-tudelft/vhsnunzip

4

Encoded identifiers

additional data beat is provably sufficient for runs overlapping data beats, so the module keeps exactly two data beats in a register and tracks a data offset and a varint offset into it. Whenever consuming a run advances the data offset past the end of the first data beat, the second beat is shifted down into the first half of the register, both offsets are reduced by 64, and the freed upper half receives the next incoming data beat. Offsets thus grow monotonically within a fixed 128-byte window, and every run extraction is a simple partselect at a byte offset. One important subtlety is that the shift takes effect at the next clock edge, so values captured in the same cycle, such as the varint decoder’s input bytes, must be indexed with preshift offsets. Both RLE and BPE sub-decoders have several cycles of latency between input and output because they are internally pipelined to keep the critical path short. We therefore decouple the input-driving logic from the output: whenever a sub-decoder is fed, a selector value is pushed onto a FIFO. The head of that FIFO configures the multiplexer connecting the sub-decoders to the output. This way the state machine can advance to the next header while the previous run’s values are still in flight, and outputs are guaranteed to appear in the correct sequence. Wiring the varint decoder for the run header combinatorially from the registered data through the offset would create a very long path through a wide multiplexer. Instead, the next varint offset is precomputed and the varint decoder’s input registers are only populated once the data beat that actually contains the next header has been ingested. This breaks the header decoding out of the critical path while still allowing the transition from one run to the next in a single clock cycle. We constrain the number of output identifiers per data beat to a multiple of eight, which guarantees byte-aligned offsets after every decoding step. Similarly, we exploit two properties of real-world Parquet writers: they cap the number of values per page at roughly 1 Mi, which shrinks all value-count signals from 32 down to 21 bits, and they cap dictionaries at roughly 1 MiB (we support 2 MiB, i.e., 219 32 bit entries), which shrinks all identifier and bit-width signals down to 19 bits. In hardware, we are not constrained to data types that are a multiple of 8 bit wide so this saves a lot of resources. Neither constraint sacrifices generality in practice: the design still decodes any Parquet file produced by real-world writers.

4.4

Type-aware identifier splitter 4

31

4

4

0

4

31

4 →0

4

1

4

31

0

4 →0

Duplicate

4

31

0

0

Creditor & serial number Deduplicator Decoupler

Bank

Bank

Bank

Bank

Bank

Bank

Bank

return

Bank

NxM crossbar Credit

MxN crossbar Reorder Reorder Reorder Reorder

mask Keep mask

Coupler Duplicator Decoded values

Figure 5: Type-aware dictionary with 8 banks and a detailed deduplicator pipeline for four ports. mapping onto the underlying banks is trivial: each value occupies one cell in one bank, and each identifier retrieves exactly that cell. For 64-bit values, we split each value into two 32-bit halves and store them in separate banks. On lookup, each identifier 𝑚 is expanded into the two identifiers 2 · 𝑚 and 2 · 𝑚 + 1, and the two cells retrieved from separate banks are concatenated to reconstruct the original 64-bit value. Filling a full 64-byte output data beat with 32-bit values thus requires 16 identifiers per cycle, which is why the run decoder is specialized to produce 16 identifiers per data beat: with this parameterization, the dictionary can sustain full throughput for both data type widths. Since dictionary-encoded columns typically have low cardinality, they frequently contain repeated identifiers after hybrid encoding, which are all routed to the same bank and serialize there, as each bank can only serve one request per cycle. To avoid these bank conflicts, we add a deduplicator in front of the crossbar which compares every identifier lane of a data beat against all lanes preceding it. If a lane matches an earlier lane, it is marked as a duplicate that is not forwarded to the crossbar. The resulting duplicate mask, which stores the index of the first occurrence of the identifier, is forwarded to a duplicator at the end of the dictionary pipeline, where
the duplicates are materialized. The 16 2 = 120 pairwise comparisons required per data beat (we only show four lanes in Figure 5) are distributed over four pipeline stages such that each stage performs a roughly equal share of the comparisons, keeping the wide comparator logic off the critical path. Deduplication thereby turns the worst-case conflict pattern—long runs of a single identifier, as commonly emitted by the run decoder—into a single bank lookup followed by a broadcast, so the dictionary sustains full throughput even on heavily skewed identifier streams.

Type-aware Dictionary

The dictionary is the final stage of the hybrid-encoded page pipeline and is responsible for mapping the stream of identifiers produced by the run decoder back to the actual column values. As the base for this step, we use the dictionary from the libSTF, a library of standard data processing components for specialized hardware2 , which is based on the crossbar and reordering design of Dann et al. [10]. However, the original dictionary operates on fixed-width entries and has no notion of values whose width (32- or 64-bit) depends on the column’s data type. Since the dictionary is by far the heaviest component of the column-chunk decoder in terms of resources, we do not want to simply instantiate two of them to cover both value widths. We propose a new type-aware dictionary with a fixed 64-byte datapath that extends the existing design with a type-aware identifier splitter (cf. Figure 5). For 32-bit values, the

4.5

Limitations

Oasis is able to decode column chunks written by the DuckDB and Arrow Parquet writers of any fixed-size 32-bit and 64-bit data types. We do not yet support string columns or other compression schemes than Snappy. However, decoding string columns will reuse large parts of the existing infrastructure including the decompressor

2 https://github.com/fpgasystems/libstf

5

Database system

Oasis scheduler

Oasis scan operator

Job queue

Worker thread

2

Decoder state

(Pre)fetch group

0 ...

3

String decoding 1

5

3

Scheduler thread Interrupt handler

Filtering

5 Oasis SmartNIC

Main memory ...

4

Output writer

Huge-page memory pool

Pre-allocated buffers

16

6

Column-chunk decoder Column-chunk decoder Column-chunk decoder

Data fetcher

Result future

as the compression scheme and number of expected values, and the address of the pre-allocated buffer. The worker then submits this decoding job to the Oasis scheduler job queue. Submission is non-blocking: the job is placed on an unbounded queue, and the worker receives a result future. To increase overlap of decoding and query processing, workers may prefetch multiple row groups ahead of consumption. (3) The scheduler thread dispatches queued flows onto hardware streams (explained in more detail in Section 5.1.2). (4) The hardware fetches, decodes, and writes results directly into the pre-allocated host buffers. (5) The hardware then raises one interrupt per completed buffer, encoding the stream id, the number of bytes written, and a last flag. The interrupt handler passes this information on to the scheduler. (6) The worker consumes buffers from its result future and maps them zero-copy into the database system’s in-memory format. A worker whose future is empty is descheduled through the database system’s asynchronous task mechanism and woken by the interrupt-triggered completion.

Column-chunk decoder

Figure 6: Control flow: worker threads submit decoding jobs to the Oasis scheduler, which schedules them onto the set of hardware decoders. Decoded data is written into preallocated host buffers for zero-copy handoff and passed back to the worker threads via interrupt-triggered result futures.

5.1.1 Memory-mapped Configuration. All control flow uses configuration registers exposed over Oasis’s memory-mapped PCIe control interface. The configuration register file is self-describing: a global configuration region advertises a system identifier and a table of 64-bit sub-configuration identifiers with their register address space bounds. Each configuration register is backed by a FIFO of 64 slots. At startup, the SAL enumerates this table and instantiates a configuration driver for each sub-configuration, with per-stream register groups inside each sub-configuration’s address space (e. g., the data fetcher exposes address, length, and RDMA queue pair registers per stream). One software binary thus drives any synthesized configuration regardless of decoder count, local or remote data fetchers, or optional profilers, and fails gracefully when a feature is absent from the hardware design.

and run decoder. Only the dictionary would have to change for string decoding. Similarly, other decompression cores (e. g., for gzip or zstd) can be plugged into our architecture with only a light wrapper. This has been shown to work in hardware in the past [8]. Parquet defines a number of different encodings of which we support plain, dictionary, and hybrid RLE/BPE encoding. A recent study of real-world data sets [31] shows that Parquet writers effectively exclusively use these encodings. Additionally, we focus on non-nested relational tables without null values.

5

End-to-end System Integration

This section describes how Oasis is integrated into a full database system. The central challenge is a mismatch in concurrency: a database executes queries with a large, potentially unbounded number of worker threads, while Oasis offers a small, fixed number of column-chunk decoders. The software stack bridges this gap while keeping the datapath zero-copy and the worker threads unblocked.

5.1

5.1.2 Oasis Scheduler. The scheduler multiplexes the unbounded flow queues onto a fixed number of hardware streams with a greedy policy. Flows are classified by the capability they require: decode flows must run on a stream with a decoder, whereas bypass flows must run on the bypass stream. Each capability has its own queue, so a capability whose streams are saturated never head-of-line blocks the other. Internally, the scheduler tracks per-stream state consisting of an occupancy counter, which records the number of flows currently enqueued on that stream, and a dispatch lock that serializes enqueuing flows. On submission, the scheduler may take a fast path: if at least one stream of the corresponding capability is not saturated, the job’s flows are dispatched directly to the leastloaded stream. Otherwise, they are appended to the corresponding queue and dispatched later. Whenever an interrupt arrives, the scheduler thread is woken up, decrements the occupancy counter of the corresponding stream and dispatches the oldest queued flow of the matching capability. Since completions on one stream arrive in order, the interrupt handler matches each interrupt against the stream’s FIFO of pending buffers and publishes the buffer on the result future of the owning job. The last flow closes the future. Greedy dispatch is sufficient because flows are independent and uniform in shape: fairness follows from the FIFO order of the queues, and load balance from always choosing the least-loaded stream.

Oasis Software Abstraction Layer

The Oasis software abstraction layer (SAL) hides the accelerator behind an asynchronous submission interface. It makes only two assumptions: scans are executed by parallel worker threads, and the database can suspend a task that waits on a future (systems that do not support this can block the worker thread instead). Scanning a Parquet file proceeds in six steps (cf. Figure 6). (1) A worker thread claims a unit of work (e. g., a Parquet row group) and pre-allocates an output buffer per projected column chunk from a pinned memory pool that is pre-mapped into Oasis’s TLB. The exact decoded size is known in advance based on the file metadata. (2) The worker thread then constructs a decoding job: a set of operator flows, one per column chunk, each a set registers of the memory-mapped configuration that must be written. The registers include the file offset and size of the encoded column chunk that the data fetcher uses to fetch the input data, metadata about the column chunk such 6

1 2 3 4 5 6

per string column. While the FPGA decodes, the worker is never blocked: if the head group’s results are not yet ready, the scan returns an asynchronous task and DuckDB reschedules it once the hardware signals completion through the result future. Decoded column buffers are handed to the engine zero-copy and are sliced in lockstep into 2,048-row vectors. Output vectors point directly to the Oasis-written buffers, whose lifetimes are tied to the vectors by shared ownership. Queries that consume no column values (e.g., COUNT(*)) are answered directly from the Parquet metadata. Variable-length columns are not yet supported by the hardware column-chunk decoders. We thus fall back to DuckDB’s native Parquet column readers on the CPU for string columns. To avoid synchronous remote reads on this path, the compressed bytes of string column chunks are fetched through the same decoding job as bypass flows and staged in host memory, where the CPU readers consume them. String predicates are evaluated during decoding, for dictionary-encoded pages once per dictionary entry rather than once per row. Following the late-materialization order of the filter pipeline, the remaining string columns are decoded only for rows that survive all predicates. Pages whose rows are entirely filtered out are skipped without ever being read.

SELECT sum(l_extendedprice * l_discount) AS revenue FROM read_oasis('rdma://lineitem.parquet') WHERE l_shipdate >= CAST('1994-01-01' AS date) AND l_shipdate < CAST('1995-01-01' AS date) AND l_discount BETWEEN 0.05 AND 0.07 AND l_quantity < 24;

Figure 7: TPC-H benchmark query 6 using the Oasis extension’s read_oasis() table function. 5.1.3 Stream Profiling. Attributing bottlenecks inside the accelerator is difficult from the host, so each decoder carries a hardware stream profiler on its input and output. Per stream, the profiler counts handshake cycles, starved cycles (the consumer waits for data), stalled cycles (the producer is back-pressured), and idle cycles between consecutive transfers on a stream. Counting starts with the first handshake and trailing idle time is excluded, so the counters cover exactly the active window. The counters are read destructively through configuration registers, meaning they are reset once read. This lets us distinguish, per decoder, whether utilization is lost to data starvation or to back-pressure from the output.

5.2

5.2.2 RDMA Server. The RDMA server exposes a set of Parquet files as a single memory region through RDMA to as many queue pairs as the client side establishes. The raw bytes of the Parquet files are packed back-to-back and prefixed with a directory of file names, offsets, and lengths, so a client can bootstrap by reading the directory and then issue reads for arbitrary byte ranges of any file by translating them into offsets within the region. Connection setup follows an out-of-band queue-pair metadata exchange over TCP. The client opens one connection per read-request stream, and the server creates a new queue pair per connection, serving several queue pairs concurrently against the shared region. After setup, the server’s CPU is not involved in the datapath: all transfers are one-sided RDMA reads issued by the client and served entirely by the NIC, while the TCP connection is retained only as a liveness signal to tear down the queue pair when the client disconnects.

Oasis DuckDB Extension

Finally, we describe the DuckDB extension for our Oasis SmartNIC that integrates it end-to-end into the query processing of DuckDB as a table function (i. e., scan operator). We also describe the RDMA server that we use to expose the Parquet files over the network. In future work, we will add support for S3-compatible storage APIs through HTTP. For metadata operations and the DuckDB Parquet extension baseline, we also implement an RDMA file system based on the DuckDB file system extension hook. 5.2.1 read_oasis() Table Function. The Oasis extension exposes SmartNIC-accelerated scanning of Parquet files as a new table function called read_oasis(), a drop-in replacement for DuckDB’s read_parquet() that can be used in arbitrary SQL queries (cf. Figure 7) in place of regular in-memory tables. Table functions in DuckDB return metadata such as the table schema and cardinality estimates during bind time (after the query is parsed, before it is planned). Thus, at bind time, our table function reads the Parquet footer through the bypass stream of Oasis and reports the bind information to the planner. Our table function supports projection pushdown, filter pushdown, and filter pruning, so only referenced columns are fetched and decoded, filter-only columns are dropped from the operator’s output, and dynamic filters produced by hash joins at run time are merged into the pushed-down filter set before the first row group is scanned. Pushed-down predicates are applied at three levels: row groups whose column statistics evaluate a predicate as always-false are skipped entirely, predicates that the statistics prove always-true are excluded from the runtime filter set, and the remainder is evaluated on the decoded vectors. The table function plugs into DuckDB’s morsel-driven parallelism: each worker thread claims row groups from a shared cursor and keeps a configurable number of them in flight (prefetching), submitting each as an independent decoding job to the Oasis scheduler with one decode flow per fixed-width column and one bypass flow

5.2.3 RDMA Virtual File System. On the client side, the Oasis DuckDB extension registers a read-only virtual file system with DuckDB that resolves paths under the rdma:// scheme against the RDMA server’s memory region. The existing Parquet machinery (globbing, footer and metadata parsing, column-chunk reads) works on remote files unchanged. On first access, the file system establishes the RDMA queue pairs (one for each stream) and bootstraps the file directory once: it reads the first eight bytes of the region to learn the directory size, fetches the directory in a single transfer, and parses it into an in-memory map from file name to region offset and length. Opening a file then merely amounts to a local lookup in this map, and a file handle translates file-relative byte ranges into offsets within the remote region. Notably, our Oasis SmartNIC is always the RDMA endpoint on the client side, not a separate host NIC: every read is issued by Oasis as a one-sided RDMA read, and reads for the software (e.g., Parquet footers and metadata) are routed still through the bypass stream. As in other virtual file systems in DuckDB, we also coalesce column-chunk reads based on a tunable maximum byte gap between reads. 7

6

Output tput. (GiB/s)

Component Col.-chunk decoder (4x) Page-header parser Snappy decompressor Run decoder Type-aware dictionary Stream normalizer Other Other (Config, I/O, ...) Coyote shell RDMA stack Overall

LUTs Registers BRAM URAM 84.4K (6.47%) 123K (4.73%) 16 (0.79%) 72 (7.50%) 5718 (0.44%) 4199 (0.16%) 0 (0.00%) 0 (0.00%) 10.6K (0.82%) 9060 (0.35%) 0 (0.00%) 8 (0.83%) 17.0K (1.31%) 3458 (0.13%) 6 (0.30%) 0 (0.00%) 42.8K (3.29%) 94.5K (3.63%) 10 (0.50%) 64 (6.67%) 3525 (0.27%) 4714 (0.18%) 0 (0.00%) 0 (0.00%) 4622 (0.35%) 7310 (0.28%) 0 (0.00%) 0 (0.00%) 26.2K (2.01%) 46.7K (1.79%) 85 (4.22%) 45 (4.69%) 338K (25.9%) 586K (22.5%) 479 (23.7%) 54 (5.62%) 198K (15.2%) 382K (14.7%) 250 (12.4%) 54 (5.62%) 701K (53.8%) 1125K (43.2%) 628 (31.1%) 387 (40.3%)

Width 16

Single issue Dual issue 2.0 1.5 1.0 0.5 0.0 100 0 25 50 75 Copies (%)

0

25 50 75 Copies (%)

100

Figure 8: Snappy decompressor throughput and speedup for 8- and 16-byte datapath and single and dual issue copies. Data Sets. To generate the data sets, we use the TPC-H extension of DuckDB and write the resulting tables to Parquet files with the default DuckDB Parquet writer settings. DuckDB emits row groups of 122,880 rows, splitting purely by row count with no byte-based limit. By default, all pages are Snappy compressed. For each column chunk, the writer first builds a dictionary over all values of the row group and uses dictionary encoding unless the number of distinct values exceeds one fifth of the row group’s rows, in which case it falls back to plain encoding. Dictionary indices are written with ⌈log2 𝑑⌉ bits for a 𝑑-entry dictionary using the hybrid RLE/BPE scheme: a value repeated at least 4 times is emitted as an RLE run (with unbounded run length), while shorter runs are accumulated into bit-packed blocks of 256 values. Data pages are only split once they reach 100 MiB of uncompressed data, so at this row group size each column chunk in practice contains a single data page. We also tried TPC-H files written with the Arrow Parquet writer, but those achieve worse overall query throughput in DuckDB because Arrow’s default row groups of 220 rows are roughly 8.5× larger than DuckDB’s, yielding far less parallelism for decoding and query execution. In general, Oasis supports files written by both writers.

Experimental Evaluation

We implement the Oasis SmartNIC as an FPGA prototype based on the SCENIC stream computation-enhanced SmartNIC [42], Coyote v2 FPGA operating system [43], and RoCE BALBOA data center RDMA stack [18]. Oasis is embedded into Coyote as a virtual FPGA (vFPGA) and utilizes the network stack, virtual memory management, memory-mapped configuration registers, and interrupt interface. The source and benchmark code is open source3 and can be used with any FPGA supported by Coyote v2.

6.1

4 3 2 1 0

Speedup

Width 8

Table 1: Resource utilization of the Oasis SmartNIC (4 column-chunk decoders) on an AMD Alveo U55C FPGA.

Experimental Setup

System Setup. For our experiments, as the compute node, we work with a server equipped with an AMD Alveo U55C FPGA board with a 100G network port plugged into the host server via PCIe v3. The system features an AMD EPYC 7302P 16-core CPU with 32 hyper threads clocked at a maximum of 3.0GHz and 64GB of memory. We use a server equipped with the same hardware plus a Mellanox ConnectX-6 100G RDMA NIC as the storage server. Both servers are connected through a 100G switch. To synthesize the hardware, we use Vivado 2024.2 with the BUILD_OPT timing optimization flag enabled in Coyote. We use DuckDB pinned to commit hash 15d3f23 which added Parquet async I/O and do not have to modify DuckDB in any way. Everything for the Oasis integration is implemented as a DuckDB extension that can be loaded into any DuckDB instance of that version. All software is compiled with GCC 11.4.0 and CMAKE_BUILD_TYPE set to Release. Resource Utilization. Hardware designs grow spatially in the resources that they physically occupy on the chip while adding more and more functionality. Table 1 shows the resource utilization of the Oasis SmartNIC for a design with four hardware column-chunk decoders. The three largest components of the column-chunk decoder are the decompressor, run decoder, and type-aware dictionary. The type-aware dictionary specifically is the largest component because of its crossbar components that distribute the encoded identifiers to the dictionary banks and the >1 MiB on-chip memory per instance implemented mostly as URAMs that store the dictionary. The other resources used by the Oasis design are mostly from the output writer and configuration components. The Coyote shell, specifically the RDMA datapath, takes up another major part of the hardware design. Overall, the design takes up less than 50% of the resources of the chip leaving ample room for more functionality.

6.2

Microbenchmarks

We first evaluate the performance of the hardware design and its optimizations through microbenchmarks with synthetic data. 6.2.1 Snappy Decompressor Optimizations. Figure 8 shows the different optimization stages of the Snappy decompression module on synthetic data with a varying fraction of literals to copies. The baseline retires a single token per clock cycle over an 8-byte datapath. We independently widen the datapath to 16 bytes and add dual issue of copies, and report speedup over the baseline at the same copy fraction. The two optimizations address opposite ends of the copy fraction scale. On pure literal input, throughput is limited by how many bytes the datapath moves per cycle, so doubling the width to 16 bytes doubles throughput from 1.7 to 3.5 GiB/s, while dual issue is inconsequential and the two curves coincide. At almost 100 % copies, the limit is instead the token rate: an average copy is far shorter than the datapath is wide, so the wide datapath idles and the single-issue 16-byte variant falls back onto the baseline at 1.0 GiB/s. Here, retiring two copies per clock cycle increases throughput by 1.6× at a width of 8 bytes and 1.8× at 16 bytes. Consequently, each optimization on its own leaves a region of the input distribution in which it contributes nothing and the corresponding curves decay to the baseline. Combined, they are complementary and yield at

3 https://github.com/celeris-labs/oasis

8

(b) Bit-packing decoding

Run length (4, 16, 2)

1

4

7

10 13 16 19 1 Bit width

32-bit

Run length (32, 512, x2)

4

7

10 13 16 19 Bit width

Figure 9: Hybrid run decoder throughput in billions of values per second for run-length decoding and bit-packing decoding for varying bit widths and run lengths.

12.5 10.0 7.5 5.0 2.5 0.0

64-bit

Without deduplication 3.0 2.5 2.0 1.5 1.0 0.5 0.0 0.5 1.0 1.5 2.0 0.0 Zipf skew

With deduplication

Tput. (B values/s)

(a) Run-length decoding

Throughput (GB/s)

Throughput (B values/s)

3.5 3.0 2.5 2.0 1.5 1.0 0.5 0.0

0.0

0.5

1.0 1.5 Zipf skew

2.0

Figure 10: Type-aware dictionary throughput in gigabytes per second and billions of values per second for 32- and 64-bit values with and without deduplication under varying skew.

least 1.45× over the whole range. The minimum at a copy fraction of 0.25 is where neither bottleneck dominates: the literal path is no longer saturated, but copies are still too sparse for dual issue to pay off. The fully optimized module also degrades most gracefully in absolute terms, sustaining at least 1.6 GiB/s across all input distributions, whereas the baseline drops to 1.0 GiB/s.

parameter space, and the bottleneck shifts from the run rate for short run-length encoded runs to the output interface for long ones and to the unpacking of individual values for wide bit-packed runs. 6.2.3 Type-aware Dictionary. Figure 10 shows the throughput of the type-aware dictionary in gigabytes per second and in billions of values per second for 32- and 64-bit values with and without deduplication of dictionary identifiers. We again measure on the output of the dictionary and count only the non-idle clock cycles. We generate the dictionary indices from a Zipf distribution and sweep the skew parameter from 0.0, i.e., a uniform access pattern, to 2.0, where a small number of dictionary entries accounts for almost all accesses, to cover the range from unique-heavy to highly repetitive columns. Up to a skew of around 0.75, the dictionary runs at a constant 11.4 gigabytes per second independent of the value type, which is exactly the property we designed it for with the capability to tolerate localized bank conflicts. The datapath is limited by its width and not by the number of values it resolves, so the 32-bit configuration sustains 2.9 billion values per second where the 64-bit configuration sustains 1.4 billion values per second at the same byte rate. Beyond a skew of around 0.75, accesses start to concentrate on a few hot dictionary entries and, without deduplication, the resulting bank conflicts have to be serialized. Throughput then collapses to 1.6 gigabytes per second for 32-bit and 3.1 gigabytes per second for 64-bit values at a skew of 2.0. The 32-bit configuration degrades more severely in bytes per second because it resolves twice as many values per clock cycle and therefore produces twice as many conflicting accesses. This is also why both configurations converge to around 0.4 billion values per second in the right plot of Figure 10: once we are conflict bound, the limit is the rate at which we can serialize accesses per value and is no longer a function of the value width. With deduplication, the same conflicts are resolved by collapsing repeated indices into a single dictionary access instead of serializing them. The worst case moves to a skew of around 1.25 with 8.2 gigabytes per second for 32-bit and 9.3 gigabytes per second for 64-bit values, since at intermediate skew a batch still contains several distinct hot values that cannot be merged into one access. For higher skew, throughput recovers because almost all values in a batch are identical and collapse into a single access. The bottleneck of the dictionary therefore shifts between the datapath width for low-skew data and the serialization of conflicting accesses for high-skew data, and deduplication bounds the worst case to a moderate dip instead of a collapse.

6.2.2 Hybrid Run Decoding. Figure 9 shows the throughput of the hybrid run decoder in billions of values per second measured on the output of the hybrid run decoder for run-length decoding and bit-packing decoding separately. We sweep bit widths from 1 to 19 bits, which cover the whole value range practically possible for 1 MiB dictionaries. We vary the run length between 4 and 16 values in steps of two for run-length encoded runs and between 32 and 512 values in powers of two for bit-packed runs. DuckDB does not create smaller RLE runs than 4 values and packs 256 values into each BPE run. For run-length decoding in Figure 9(a), throughput is largely independent of the bit width across the entire sweep. This is expected since a run-length encoded run carries exactly one value that is replicated by the decoder, so the bit width only changes how many bits are consumed on the input side and never how many values are produced per clock cycle. Instead, throughput scales linearly with the run length from around 0.9 billion values per second at a run length of 4 to around 3.4 billion values per second at a run length of 16, since the decoder retires one run per clock cycle and the run length directly determines how many output values that run expands to. The scaling flattens for the longest runs where we reach the width of the output interface and further increasing the run length can physically not produce more values per clock cycle. For bit-packing decoding in Figure 9(b), the picture is inverted. Here, every value has to be extracted individually from the packed input, so the bit width directly determines how many values we can unpack per clock cycle and throughput decreases monotonically from around 3.2 billion values per second at a bit width of 4 to around 2.4 billion values per second at a bit width of 19. The run length has a much weaker effect than for run-length decoding and mainly amortizes the per-run overhead of consuming the run header and filling the pipeline. Consequently, the curves converge for run lengths of 128 values and above, while only the shortest bitpacked runs of 32 and 64 values pay a significant penalty of roughly half a billion values per second. Increasing the BPE run length in the DuckDB Parquet writer would not yield higher throughput. Our design is well tuned for it. Overall, the hybrid run decoder sustains between 2 and 3.5 billion values per second across the relevant 9

Scan throughput (GB/s)

Oasis (1-4 decoders)

the remote storage described above and is accessed through RDMA. We warm the Parquet metadata cache of DuckDB beforehand to avoid network roundtrips for metadata fetching from skewing the end-to-end runtime, disable external file caching, and enable profiling so we can extract per-operator runtimes. Each measurement point is the mean of three measurements. In Figure 12, we show the results with the TPC-H queries on the x-axis and the query runtime in seconds on the y-axis. We are most interested in the relative runtimes of the baseline on the left of each query group compared to Oasis runtime on the right. For the baseline, we split up the query runtime into the scan and remaining query runtime. The scan runtime includes pushed-down filters. As expected, we see that the remaining query runtime remains the same for all queries. For the scan runtime itself, we see stark improvements cutting the total query runtime in half for a lot of queries. For queries such as Q3, Q5, Q8, Q9, Q11, Q16, and Q18, we fully overlap the scan runtime with the remaining query runtime to fully hide the scan in the network datapath. Only a small overhead remains for setting up the output buffers and the control flow. For the other queries, we observe two major remaining overheads in the scan runtime. For queries Q1, Q10, Q13, Q19, and Q22, we still see significant runtime for string decoding. Two queries stick out in particular. Q10 is pronounced because we decode five large string columns: c_name, c_phone, c_address, c_comment, and l_returnflag. For Q13, we decode the largest string column o_comment and apply a NOT LIKE filter which counts towards the string decoding time. The second major overhead in the scan operators is pusheddown filters for queries Q4, Q6, Q7, Q17, Q20, and Q21. For Q4, the filter runtime is dominated by a pushed-down dynamic range filter on l_orderkey and optional Bloom filter from the subsequent join. We see purely static filters for Q6 where the query is a single filtered aggregation over lineitem, and evaluating the three pusheddown predicates on l_shipdate, l_discount, and l_quantity makes up 79% of its scan runtime. Q17 is the opposite: its lineitem scan has only dynamic range and Bloom filters on l_partkey created by the highly selective scan of part, where the predicates on p_brand and p_container retain only ∼0.1% of the rows. Finally, Q21 accumulates the largest absolute filter runtime of all queries because its EXISTS and NOT EXISTS subqueries scan lineitem three times, each time evaluating dynamic filters on l_orderkey and l_suppkey produced by the joins. Overall, we can hide almost the whole scan operator runtime in the network datapath except the pushed down filters and string decoding. These now take up 84% of the remaining scan runtime or summed across the total query runtime, ∼15% each across all queries.

15.0 12.5 10.0 7.5 5.0 2.5 0.0

t r y y x y y e e e e erke artke ppke dpric umbe antit coun l_tashipdat mitdateiptdat l_ l_com l_rec l_ord l_p l_suxtende l_linen l_qu l_dis l_e TPC-H lineitem column

Figure 11: TPC-H (scale factor 30) lineitem table per-column decoding throughput in gigabytes per second of our Oasis SmartNIC using 1-4 hardware column-chunk decoders.

6.2.4 Per-column Decoding Throughput. In our last microbenchmark, Figure 11 shows per-column decoding throughput measured at the output of the hardware decoders. The measurement counts only the clock cycles in which we actually transport data, excluding the idle cycles between transfers, to isolate raw decoding performance. We use the non-string columns of the lineitem table as representation columns across the TPC-H benchmark. In general, we are limited by the PCIe interconnect available on this hardware. We observe three classes of columns characterized by their input data properties and the resulting performance. First, the key columns and the price column of lineitem are Snappy-compressed with a high fraction of copies but have a low encoding ratio. A single hardware decoder is therefore limited to the throughput of the Snappy decompressor, since the data does not grow in the subsequent decoding stages of the datapath. However, performance scales perfectly across hardware decoders. Second, the line number, quantity, discount, and tax columns also contain many copies in the Snappy-compressed input, but have a high encoding ratio because they hold relatively few unique values. The Snappy decompressor remains the slowest stage, but decoding inflates the data enough that a single hardware decoder almost saturates the PCIe link. Third, literal-heavy columns such as the date columns are essentially uncompressed, so the Snappy decompressor passes the data through at full line rate and is no longer the bottleneck. The bottleneck of the hardware decoders thus shifts between the Snappy decompressor and the PCIe interconnect depending on the characteristics of the input data, which is why we scale to multiple decoder instances.

6.3

End-to-end Scan Performance

We now show the end-to-end performance of the Oasis extension scan operator on the TPC-H benchmark in a per-query runtime and throughput benchmark setting.

6.3.2 DuckDB Query Throughput. In our second end-to-end experiment we measure query throughput as per the TPC-H throughput benchmark. We again use the same TPC-H scale factor 30 Parquet files on our remote storage server accessed through RDMA. We also again warm the Parquet metadata cache of DuckDB beforehand and disable external file caching. We restrict the number of worker threads with DuckDB to 𝑛 and also pin the execution to the first 𝑛 cores/hyper-threads of the CPU with numactl because we noticed that just setting the number of threads in DuckDB is not reliable. The benchmark sets up four connections (i. e., streams) to DuckDB

6.3.1 Per-query Scan Runtime. In our first end-to-end experiment, we look at scan operator performance for each of the 22 TPC-H queries compared to the Parquet scan operator of the DuckDB Parquet extension. DuckDB is configured to use 8 worker threads and four hardware decoders when using Oasis. Again, we use Snappy compressed Parquet files written by DuckDB with default settings with scale factor 30 of the TPC-H data set. The data is stored on 10

7.5

DuckDB Parquet scan Oasis scan (CPU string decode)

Runtime (s)

6.0

Remaining query Oasis scan (CPU filter)

Oasis scan (overhead)

4.5 3.0 1.5 0.0

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20 Q21 Q22 TPC-H query

Figure 12: TPC-H (scale factor 30) benchmark per-query runtime in seconds comparing the baseline DuckDB Parquet extension to our Oasis SmartNIC using 4 hardware decoders both with 8 DuckDB worker threads. The remaining query runtime, excluding the scans, stays the same while the scanning can be overlapped with the query runtime.

Oasis (1-4 decoders)

Oasis (1-4 streams) Decoder utilization (%)

TPC-H throughput (Q/h)

DuckDB Parquet 6000 4000 2000 0

1

4

8

12 16 20 24 DuckDB worker threads

28

32

No prefetch

Prefetch

80 60 40 20 0

1

4

8

12 16 20 24 DuckDB worker threads

28

32

Figure 13: TPC-H (scale factor 30, four streams) throughput benchmark in queries per hour of the baseline DuckDB Parquet extension compared to our Oasis SmartNIC.

Figure 14: TPC-H (scale factor 30) throughput benchmark column-chunk decoder utilization for 1-4 streams of queries for Oasis SmartNIC with four hardware decoders.

each then submitting a randomly permuted sequence of the 22 TPCH queries in parallel. Figure 13 shows the TPC-H throughput in queries per hour on the y-axis while scaling the number of worker threads on the x-axis of DuckDB’s Parquet extension compared to our Oasis extension with 1–4 hardware column-chunk decoders. The Parquet extension baseline scales very similarly to the measurement run on local Parquet files from Figure 1 because of the low overhead of RDMA and async I/O support in the DuckDB Parquet extension that is able to hide the network latency well. Oasis scales very well, almost matching in-memory performance, up to 8 threads where it shows almost double the throughput compared to the DuckDB baseline at 4,554 queries per hour. After that, performance starts to level off because we are hitting the limit of the PCIe 3 interconnect with the decoded data. We do not see this for the DuckDB baseline because the data is only decoded after crossing this bottleneck. There, we never saturate the network bandwidth or PCIe interconnect which have roughly similar line rates. However, Oasis with four hardware column-chunk decoders is still 40% faster at the top end. Regarding scaling, we are also restricted by PCIe interconnect. One to two hardware decoders scales almost perfectly and we would expect the same for three and four decoders. Oasis therefore returns half of the cores to actual query processing rather than using them for decoding and with fast interconnects, potentially fully gets rid of the decoding overhead matching in-memory performance on Parquet files through the network.

6.3.3 Prefetching & Decoder Utilization. Finally, we take a look at how prefetching influences column-chunk decoder utilization in Oasis. We again run TPC-H throughput benchmarks at scale factor 30 with one to four streams submitting queries. Figure 14 shows the decoder utilization on the y-axis scaling across DuckDB worker threads on the x-axis for each number of streams without prefetching (i. e., async I/O but prefetching depth set to 1) and prefetching enabled (prefetching depth set to 2). Decoder utilization is calculated from the clock cycle counters of the stream profilers that sit on the output port of the decoders as the number of non-idle clock cycles relative to the total number of clock cycles. An idle clock cycle is one where we saw the last signal of the previous column chunk but didn’t see the first valid data beat of the next column chunk yet. In general, decoder utilization rises with the number of worker threads as we produce more decoding jobs in parallel. We can also see that having more streams submitting queries in parallel helps with decoder utilization since we can overlap decoding of one query with executing the CPU side of another operator pipeline more often. Finally, we see that prefetching helps with decoder utilization since we can overlap Oasis decoding with the rest of the corresponding operator pipeline. Decoder utilization caps out at 85% since we also load other string columns through the bypass stream and we have other traffic like interrupts and configuration reads and writes going through the PCIe interconnect. Overall, decoder utilization is governed by how many independent decoding jobs the database system can expose at any point in time. 11

6.4

Discussion

rate of its infrastructure, attributes this to the continuous interpretation of Parquet’s file-, row-group-, and page-level metadata during reads, and resorts to a simplified Arrow-like format to quantify the gap—while noting that the exabytes already stored in Parquet make migration impractical [6]. Oasis takes the opposite route: rather than changing the format to fit the compute, it changes the hardware to fit the format that data lakes and lakehouses actually use today. Pruning remains fully complementary. Hardware-accelerated parsing and decoding. Offloading data ingestion to specialized hardware has already been deployed at cloud scale in the past: Redshift’s AQUA was an FPGA-based acceleration layer placed between storage and compute [5]. In the research literature, offloading has been explored for a variety of formats. On FPGAs, prior work demonstrates JSON-to-Arrow conversion [39], line-rate JSON parsing [11], and, closest to our work, Parquet decoding [31, 40]. Peltenburg et al. specifically only cover a subset of the encoding and compression schemes found in practice. More importantly, both remain isolated prototypes: they are evaluated as standalone decoders, leave open where the accelerator would sit in a real deployment, and are not integrated into a database system. Oasis addresses all three gaps and most importantly integrates end-to-end into DuckDB so that decoding overlaps with query execution instead of merely being faster in isolation. Operator pushdown. An orthogonal approach to reducing scan pressure in the compute layer is to move computation closer to the data. Pushing operators into the storage layer [50, 52] and inserting intermediate layers that partially evaluate queries [5, 7] have both been explored successfully. Commercial systems follow the same principle: Google BigQuery pushes filter and projection evaluation into its Capacitor storage layer [34], and Oracle’s Exadata offloads predicate filtering, column projection, and join Bloom filters to storage [38], in both cases significantly reducing the volume of data crossing the storage–compute boundary.

Our Oasis column-chunk decoders exhibit excellent performance with throughput close to the interconnect speed with a single decoder for many columns. Only for columns with low encoding ratio, the decompression is still the limiting factor even though we doubled Snappy decompression performance with our doubled datapath width and dual copy resolution per clock cycle. In end-toend query execution, we can overlap Parquet decoding fully with CPU query runtime for many queries, completely getting rid of the massive decoding overhead. Our throughput benchmark shows that we can thus match the performance of DuckDB with its native Parquet extension and 16 worker threads with our Oasis SmartNIC on 8 worker threads. The query throughput for Oasis is mainly limited by the PCIe interconnect. The two residual overheads of the Oasis scan are string decoding and pushed-down filters that are still evaluated on the CPU. These are the natural next targets to evolve the Oasis SmartNIC. String decoding is a matter of extending the decoder pipeline with a variable-length dictionary that can output strings and a split output writer per decoder to write German string structs [37] and the dictionary itself. Implementing this would fully get rid of the Parquet decoding overhead leaving the PCIe interconnect as the bottleneck. We can relax this bottleneck by pushing down filters which would avoid sending columns to main memory that are used purely for filtering and lower the pressure on the interconnect for all other columns by reducing them to the actually relevant data that pass the filter. Together with interconnects such as PCIe 5 or CXL, this points towards scans over Parquet files on remote storage that cost no more than scans over in-memory data, and towards a division of labor in which the network datapath is responsible for turning storage formats into query-ready columns and the CPU or GPU is left with query processing alone [23].

7

Related Work

Accelerating data ingestion in cloud-native database systems has been approached from several directions: redesigning the file formats themselves, offloading parsing and decoding to specialized hardware, processing data on SmartNICs [12] and DPUs [16, 19], and pushing computation into or closer to the storage layer. OS2G [22] moves the object-storage client onto a DPU and transfers data directly from the DPU into GPU memory, bypassing the host entirely. Orthogonal to our work, there has been a lot of work on using FPGAs for individual database operators [13], from sketches [27] and integer vector compression [35] to LSM tree compaction [20, 55] and graph processing [51]. Modern file formats. A new generation of file formats replace generalpurpose block compression with nested cascades of lightweight encodings [15, 30] and organize data such that decoding maps efficiently onto the SIMD units of modern CPUs and GPUs [1]. Complementary to faster decoding, aggressive file pruning reduces the amount of data that must be decoded in the first place based on statistics over the stored data [56]. Careful engineering of the scan path narrows the gap without closing it: Rey et al. collect statistics for improved query optimization and data skipping during query evaluation [44]. A recent GPU-accelerated Presto reports reading Parquet an order of magnitude below the theoretical I/O

8

Summary and Future Work

We presented Oasis, a data-processing SmartNIC that offloads Parquet decoding into the network datapath between cloud object storage and the database system. Oasis features a set of hardware column-chunk decoders handling decoding of real-world Parquet files, a software abstraction layer for buffer management and scheduling, and end-to-end integration into DuckDB via an extension. Our evaluation shows that Oasis hides the cost of Parquet decoding in the datapath with minimal overhead, overlapping the decoding with query execution and almost doubling query throughput in the best case. In future work, we will add string column decoding, an S3-compatible HTTP stack, and operator pushdown [9].

Acknowledgments We would like to thank AMD for the donation of the Heterogeneous Accelerated Compute Cluster (HACC) at ETHZ which was used to obtain the experimental results presented in this paper. A special thanks also goes out to Geert Roks for the support of the cluster and Maximilian Heer and Benjamin Ramhorst for their continued efforts on the SCENIC and Coyote open-source projects. This work was funded in part through an unrestricted grant from AMD. 12

References

In Proceedings of the 2019 International Conference on Management of Data, SIGMOD Conference 2019, Amsterdam, The Netherlands, June 30 - July 5, 2019. ACM, 651–665. doi:10.1145/3299869.3314041 [21] Matteo Interlandi, Nicolas Bruno, Brandon Haynes, Carlo Curino, Rathijit Sen, Yinan Li, Kaushik Rajan, Bailu Ding, Lukas M. Maas, Wei Cui, Kevin Gaffney, Mingsheng Hong, Brian Kroth, Sampath Rajendra, Peng Cheng, Surajit Chaudhuri, Johannes Gehrke, Raghu Ramakrishnan, Lidong Zhou, Momin Al-Ghosien, Craig Peeper, Marius Dumitru, Conor Cunningham, Kevin Bocksrocker, Prasanna Sundar, Ron Boskovic, YongChul Kwon, Marko Zivanovic, Runbin Shi, Krystian Sakowski, Denis Lamtsov, Josep Aguilar-Saborit, Krish Srinivasan, Adarsh Kapil, Andrew Putnam, Anudeep Kambapu, Aparna Konduri, Aaron Landy, Aaron Moore, Aaron Pitman, Artem Oks, Ashit Gosalia, Babu Kandimalla, Blake Pelton, Bogdan Crivat, César A. Galindo-Legaria, Chidamber Kulkarni, Jesús Camacho-Rodríguez, Evgeny Babin, Hans Lehnert Marino, Igor Konev, Israel Arroyo, Luis Peñaranda, Mandar Datar, Morten Borup Petersen, Nicholas Simmons, Parminder Poonian, Pravija Danda, Rob Rydberg, Esteban Calvo Vargas, Ronak Bajaj, Sai Sumanth Kammal Shetty, Sharanya Bhat, and Zach Iracheta. 2026. CoddSpeed: Hardware Accelerated Query Processing in Microsoft Fabric. In Companion of the International Conference on Management of Data, SIGMOD Companion 2026, Bengaluru, India, 31 May 2026 - 5 June 2026. ACM, 359–372. doi:10.1145/3788853.3803077 [22] Zhen Jin, Yiquan Chen, Mingxu Liang, Yijing Wang, Guoju Fang, Ao Zhou, Keyao Zhang, Jiexiong Xu, Wenhai Lin, Yiquan Lin, Shushu Zhao, Wenkai Shi, Zhenhua He, Shishun Cai, and Wenzhi Chen. 2025. OS2G: A High-Performance DPU Offloading Architecture for GPU-based Deep Learning with Object Storage. In Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, ASPLOS 2025, Rotterdam, Netherlands, 30 March 2025 - 3 April 2025. ACM, 750–765. doi:10.1145/ 3676641.3716265 [23] Marko Kabic, Bowen Wu, Jonas Dann, and Gustavo Alonso. 2025. Powerful GPUs or Fast Interconnects: Analyzing Relational Workloads on Modern GPUs. Proc. VLDB Endow. 18, 11 (2025), 4350–4363. doi:10.14778/3749646.3749698 [24] Sagar Karandikar, Chris Leary, Chris Kennelly, Jerry Zhao, Dinesh Parimi, Borivoje Nikolic, Krste Asanovic, and Parthasarathy Ranganathan. 2021. A Hardware Accelerator for Protocol Buffers. In MICRO ’21: 54th Annual IEEE/ACM International Symposium on Microarchitecture, Virtual Event, Greece, October 18-22, 2021. ACM, 462–478. doi:10.1145/3466752.3480051 [25] Timo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, and Peter Boncz. 2018. Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask. Proc. VLDB Endow. 11, 13 (2018), 2209–2222. doi:10.14778/3275366.3275370 [26] Elie F. Kfoury, Samia Choueiri, Ali Mazloum, Ali AlSabeh, Jose Gomez, and Jorge Crichigno. 2024. A Comprehensive Survey on SmartNICs: Architectures, Development Models, Applications, and Research Directions. IEEE Access 12 (2024), 107297–107336. doi:10.1109/ACCESS.2024.3437203 [27] Martin Kiefer, Ilias Poulakis, Sebastian Breß, and Volker Markl. 2020. Scotch: Generating FPGA-Accelerators for Sketching at Line Rate. Proc. VLDB Endow. 14, 3 (2020), 281–293. doi:10.5555/3430915.3442428 [28] Simon Kuenzer, Vlad-Andrei Badoiu, Hugo Lefeuvre, Sharan Santhanam, Alexander Jung, Gaulthier Gain, Cyril Soldani, Costin Lupu, Stefan Teodorescu, Costi Raducanu, Cristian Banu, Laurent Mathy, Razvan Deaconescu, Costin Raiciu, and Felipe Huici. 2021. Unikraft: fast, specialized unikernels the easy way. In EuroSys ’21: Sixteenth European Conference on Computer Systems, Online Event, United Kingdom, April 26-28, 2021. ACM, 376–394. doi:10.1145/3447786.3456248 [29] Maximilian Kuschewski, Jana Giceva, Thomas Neumann, and Viktor Leis. 2024. High-Performance Query Processing with NVMe Arrays: Spilling without Killing Performance. Proc. ACM Manag. Data 2, 6 (2024), 238:1–238:27. doi:10.1145/ 3698813 [30] Maximilian Kuschewski, David Sauerwein, Adnan Alhomssi, and Viktor Leis. 2023. BtrBlocks: Efficient Columnar Compression for Data Lakes. Proc. ACM Manag. Data 1, 2 (2023), 118:1–118:26. doi:10.1145/3589263 [31] Si Jun Kwon, Zsolt István, Daniel Ritter, Norman May, and Christian Faerber. 2026. Efficient Parquet Parsing on FPGAs. In Proceedings of the 22nd International Workshop on Data Management on New Hardware, DaMoN 2026, Bengaluru, India, 31 May 2026- 5 June 2026. ACM, 3:1–3:9. doi:10.1145/3789237.3809124 [32] Viktor Leis and Christian Dietrich. 2024. Cloud-Native Database Systems and Unikernels: Reimagining OS Abstractions for Modern Hardware. Proc. VLDB Endow. 17, 8 (2024), 2115–2122. doi:10.14778/3659437.3659462 [33] Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shivakumar, Matt Tolton, and Theo Vassilakis. 2011. Dremel: interactive analysis of webscale datasets. Commun. ACM 54, 6 (2011), 114–123. doi:10.1145/1953122.1953148 [34] Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shivakumar, Matt Tolton, Theo Vassilakis, Hossein Ahmadi, Dan Delorey, Slava Min, Mosha Pasumansky, and Jeff Shute. 2020. Dremel: A Decade of Interactive SQL Analysis at Web Scale. Proc. VLDB Endow. 13, 12 (2020), 3461–3472. doi:10.14778/3415478.3415568 [35] Mahmoud Mohsen, Norman May, Christian Färber, and David Broneske. 2020. FPGA-Accelerated compression of integer vectors. In 16th International Workshop

[1] Azim Afroozeh and Peter Boncz. 2025. The FastLanes File Format. Proc. VLDB Endow. 18, 11 (2025), 4629–4643. doi:10.14778/3749646.3749718 [2] Alibaba Cloud Community. 2022. A Detailed Explanation about Alibaba Cloud CIPU. https://www.alibabacloud.com/blog/a-detailed-explanation-aboutalibaba-cloud-cipu_599183. [3] Amazon Web Services. 2022. The Components of the Nitro System (The Security Design of the AWS Nitro System Whitepaper). Technical Report. Amazon Web Services. https://docs.aws.amazon.com/whitepapers/latest/security-design-ofaws-nitro-system/the-components-of-the-nitro-system.html Accessed: 202604-15. [4] Apache Software Foundation. 2025. Apache Parquet Format Specification. https: //parquet.apache.org/. Accessed: 2026-04-30. [5] Nikos Armenatzoglou, Sanuj Basu, Naga Bhanoori, Mengchu Cai, Naresh Chainani, Kiran Chinta, Venkatraman Govindaraju, Todd J. Green, Monish Gupta, Sebastian Hillig, Eric Hotinger, Yan Leshinksy, Jintian Liang, Michael McCreedy, Fabian Nagel, Ippokratis Pandis, Panos Parchas, Rahul Pathak, Orestis Polychroniou, Foyzur Rahman, Gaurav Saxena, Gokul Soundararajan, Sriram Subramanian, and Doug Terry. 2022. Amazon Redshift Re-invented. In SIGMOD. ACM, 2205–2217. doi:10.1145/3514221.3526045 [6] Daniel Bauer, Luis Garcés-Erice, Deepak Majeti, Zoltan Arnold Nagy, Sean Rooney, Greg Kimball, Devavret Makkar, Todd Mostak, and Karthikeyan Natarajan. 2026. Accelerating Presto with GPUs. CoRR abs/2606.24647 (2026). doi:10.48550/ARXIV.2606.24647 [7] Mengchu Cai, Martin Grund, Anurag Gupta, Fabian Nagel, Ippokratis Pandis, Yannis Papakonstantinou, and Michalis Petropoulos. 2018. Integrated Querying of SQL database data and S3 data in Amazon Redshift. IEEE Data Eng. Bull. 41, 2 (2018), 82–90. [8] Monica Chiosa, Fabio Maschi, Ingo Müller, Gustavo Alonso, and Norman May. 2022. Hardware Acceleration of Compression and Encryption in SAP HANA. Proc. VLDB Endow. 15, 12 (2022), 3277–3291. doi:10.14778/3554821.3554822 [9] Jonas Dann and Gustavo Alonso. 2026. Should I Hide My Duck in the Lake?. In Proceedings of the 22nd International Workshop on Data Management on New Hardware, DaMoN 2026, Bengaluru, India, 31 May 2026- 5 June 2026. ACM, 12:1– 12:5. doi:10.1145/3789237.3809130 [10] Jonas Dann, Daniel Ritter, and Holger Fröning. 2022. GraphScale: Scalable Bandwidth-Efficient Graph Processing on FPGAs. In 32nd International Conference on Field-Programmable Logic and Applications, FPL 2022, Belfast, United Kingdom, August 29 - Sept. 2, 2022. IEEE, 24–32. doi:10.1109/FPL57034.2022.00016 [11] Jonas Dann, Royden Wagner, Daniel Ritter, Christian Faerber, and Holger Fröning. 2022. PipeJSON: Parsing JSON at Line Speed on FPGAs. In DaMoN. ACM, 3:1–3:7. doi:10.1145/3533737.3535094 [12] Faeze Faghih, Tobias Ziegler, Zsolt István, and Carsten Binnig. 2024. SmartNICs in the Cloud: The Why, What and How of In-network Processing for DataIntensive Applications. In Companion of the 2024 International Conference on Management of Data, SIGMOD/PODS 2024, Santiago, Chile, June 9-15, 2024. ACM, 556–560. doi:10.1145/3626246.3654690 [13] Jian Fang, Yvo T. B. Mulder, Jan Hidders, Jinho Lee, and H. Peter Hofstee. 2020. In-memory database acceleration on FPGAs: a survey. VLDB J. 29, 1 (2020), 33–59. doi:10.1007/S00778-019-00581-W [14] Daniel Firestone, Andrew Putnam, Sambrama Mundkur, Derek Chiou, Alireza Dabagh, Mike Andrewartha, Hari Angepat, Vivek Bhanu, Adrian M. Caulfield, Eric S. Chung, Harish Kumar Chandrappa, Somesh Chaturmohta, Matt Humphrey, Jack Lavier, Norman Lam, Fengfen Liu, Kalin Ovtcharov, Jitu Padhye, Gautham Popuri, Shachar Raindel, Tejas Sapre, Mark Shaw, Gabriel Silva, Madhan Sivakumar, Nisheeth Srivastava, Anshuman Verma, Qasim Zuhair, Deepak Bansal, Doug Burger, Kushagra Vaid, David A. Maltz, and Albert G. Greenberg. 2018. Azure Accelerated Networking: SmartNICs in the Public Cloud. In NSDI. USENIX Association, 51–66. [15] Mateusz Gienieczko, Maximilian Kuschewski, Thomas Neumann, Viktor Leis, and Jana Giceva. 2025. AnyBlox: A Framework for Self-Decoding Datasets. Proc. VLDB Endow. 18, 11 (2025), 4017–4031. doi:10.14778/3749646.3749672 [16] Dimitrios Giouroukis, Dwi P. A. Nugroho, Varun Pandey, Steffen Zeuch, and Volker Markl. 2025. Analyzing Near-Network Hardware Acceleration with CoProcessing on DPUs. Proc. VLDB Endow. 18, 13 (2025), 5689–5702. doi:10.14778/ 3773731.3773743 [17] Google LLC. [n. d.]. Snappy: A fast compressor/decompressor. https://github. com/google/snappy. Accessed: 2026-07-24. [18] Maximilian Jakob Heer, Benjamin Ramhorst, Yu Zhu, Luhao Liu, Zhiyi Hu, Jonas Dann, and Gustavo Alonso. 2025. RoCE BALBOA: Service-enhanced Data Center RDMA for SmartNICs. CoRR abs/2507.20412 (2025). doi:10.48550/ARXIV.2507. 20412 [19] Jason Hu, Philip A. Bernstein, Jialin Li, and Qizhen Zhang. 2025. DPDPU: Data Processing with DPUs. In CIDR. www.cidrdb.org. [20] Gui Huang, Xuntao Cheng, Jianying Wang, Yujie Wang, Dengcheng He, Tieying Zhang, Feifei Li, Sheng Wang, Wei Cao, and Qiang Li. 2019. X-Engine: An Optimized Storage Engine for Large-scale E-commerce Transaction Processing. 13

2025. Workload Insights From the Snowflake Data Cloud: What Do Production Analytic Queries Really Look Like? Proc. VLDB Endow. 18, 12 (2025), 5126–5138. doi:10.14778/3750601.3750632 [47] Alexander van Renen, Dominik Horn, Pascal Pfeil, Kapil Vaidya, Wenjian Dong, Murali Narayanaswamy, Zhengchun Liu, Gaurav Saxena, Andreas Kipf, and Tim Kraska. 2024. Why TPC Is Not Enough: An Analysis of the Amazon Redshift Fleet. Proc. VLDB Endow. 17, 11 (2024), 3694–3706. doi:10.14778/3681954.3682031 [48] Alexander van Renen and Viktor Leis. 2023. Cloud Analytics Benchmark. Proc. VLDB Endow. 16, 6 (2023), 1413–1425. doi:10.14778/3583140.3583156 [49] Midhul Vuppalapati, Justin Miron, Rachit Agarwal, Dan Truong, Ashish Motivala, and Thierry Cruanes. 2020. Building An Elastic Query Engine on Disaggregated Storage. In NSDI. USENIX Association, 449–462. [50] Yifei Yang, Xiangyao Yu, Marco Serafini, Ashraf Aboulnaga, and Michael Stonebraker. 2024. FlexpushdownDB: rethinking computation pushdown for cloud OLAP DBMSs. VLDB J. 33, 5 (2024), 1643–1670. doi:10.1007/s00778-024-00867-8 [51] Feng Yu, Hongshi Tan, Xinyu Chen, Yao Chen, Bingsheng He, and Weng-Fai Wong. 2025. Clementi: Efficient Load Balancing and Communication Overlap for Multi-FPGA Graph Processing. Proc. ACM Manag. Data 3, 3 (2025), 138:1–138:27. doi:10.1145/3725275 [52] Xiangyao Yu, Matt Youill, Matthew E. Woicik, Abdurrahman Ghanem, Marco Serafini, Ashraf Aboulnaga, and Michael Stonebraker. 2020. PushdownDB: Accelerating a DBMS Using S3 Computation. In ICDE. IEEE, 1802–1805. doi:10. 1109/ICDE48307.2020.00174 [53] Matei Zaharia, Ali Ghodsi, Reynold Xin, and Michael Armbrust. 2021. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. In 11th Conference on Innovative Data Systems Research, CIDR 2021, Virtual Event, January 11-15, 2021, Online Proceedings. www.cidrdb.org. [54] Xinyu Zeng, Yulong Hui, Jiahong Shen, Andrew Pavlo, Wes McKinney, and Huanchen Zhang. 2023. An Empirical Evaluation of Columnar Storage Formats. Proc. VLDB Endow. 17, 2 (2023), 148–161. doi:10.14778/3626292.3626298 [55] Teng Zhang, Jianying Wang, Xuntao Cheng, Hao Xu, Nanlong Yu, Gui Huang, Tieying Zhang, Dengcheng He, Feifei Li, Wei Cao, Zhongdong Huang, and Jianling Sun. 2020. FPGA-Accelerated Compactions for LSM-based Key-Value Store. In 18th USENIX Conference on File and Storage Technologies, FAST 2020, Santa Clara, CA, USA, February 24-27, 2020. USENIX Association, 225–237. [56] Andreas Zimmerer, Damien Dam, Jan Kossmann, Juliane Waack, Ismail Oukid, and Andreas Kipf. 2025. Pruning in Snowflake: Working Smarter, Not Harder. In SIGMOD. ACM, 757–770. doi:10.1145/3722212.3724447

on Data Management on New Hardware, DaMoN 2020, Portland, Oregon, USA, June 15, 2020. ACM, 9:1–9:10. doi:10.1145/3399666.3399932 [36] Thomas Neumann. 2011. Efficiently Compiling Efficient Query Plans for Modern Hardware. Proc. VLDB Endow. 4, 9 (2011), 539–550. doi:10.14778/2002938.2002940 [37] Thomas Neumann and Michael J. Freitag. 2020. Umbra: A Disk-Based System with In-Memory Performance. In 10th Conference on Innovative Data Systems Research, CIDR 2020, Amsterdam, The Netherlands, January 12-15, 2020, Online Proceedings. www.cidrdb.org. http://cidrdb.org/cidr2020/papers/p29neumanncidr20.pdf [38] Oracle Corporation. 2012. A Technical Overview of the Oracle Exadata Database Machine and Exadata Storage Server. White Paper. Oracle Corporation. https://www.oracle.com/technetwork/server-storage/engineered-systems/ exadata/dbmachine-x3-twp-1867467.pdf. [39] Johan Peltenburg, Ákos Hadnagy, Matthijs Brobbel, Robert Morrow, and Zaid Al-Ars. 2021. Tens of gigabytes per second JSON-to-Arrow conversion with FPGA accelerators. In FPT. IEEE, 1–9. doi:10.1109/ICFPT52863.2021.9609833 [40] Johan Peltenburg, Lars T. J. van Leeuwen, Joost Hoozemans, Jian Fang, Zaid Al-Ars, and H. Peter Hofstee. 2020. Battling the CPU Bottleneck in Apache Parquet to Arrow Conversion Using FPGA. In FPT. IEEE, 281–286. doi:10.1109/ ICFPT51103.2020.00048 [41] Mark Raasveldt and Hannes Mühleisen. 2019. DuckDB: an Embeddable Analytical Database. In SIGMOD. ACM, 1981–1984. doi:10.1145/3299869.3320212 [42] Benjamin Ramhorst, Maximilian Jakob Heer, Luhao Liu, Heejae Kim, Jonas Dann, Jin-Soo Kim, and Gustavo Alonso. 2026. SCENIC: Stream Computation-Enhanced SmartNIC. CoRR abs/2604.15128 (2026). doi:10.48550/arXiv.2604.15128 [43] Benjamin Ramhorst, Dario Korolija, Maximilian Jakob Heer, Jonas Dann, Luhao Liu, and Gustavo Alonso. 2025. Coyote v2: Raising the Level of Abstraction for Data Center FPGAs. In SOSP. ACM, 639–654. doi:10.1145/3731569.3764845 [44] Alice Rey, Michael Freitag, and Thomas Neumann. 2023. Seamless Integration of Parquet Files into Data Processing. In Datenbanksysteme für Business, Technologie und Web (BTW 2023), 20. Fachtagung des GI-Fachbereichs „Datenbanken und Informationssysteme" (DBIS), 06.-10, März 2023, Dresden, Germany, Proceedings (LNI, Vol. P-331). Gesellschaft für Informatik e.V., 235–258. doi:10.18420/BTW202312 [45] Mark Slee, Aditya Agarwal, and Marc Kwiatkowski. 2007. Thrift: Scalable CrossLanguage Services Implementation. Technical Report. Facebook. https://thrift. apache.org/static/files/thrift-20070401.pdf [46] Jan Vincent Szlang, Sebastian Breß, Sebastian Cattes, Jonathan Dees, Florian Funke, Max Heimel, Michel Oleynik, Ismail Oukid, and Tobias Maltenberger.

14

Related documents

• AVPKEET: Exact-Request Authorization and Publicly Verifiable Equality Testing over Encrypted Data#677629
• AVPKEET: Exact-Request Authorization and Publicly Verifiable Equality Testing over Encrypted Data#674428
• Coherent File Distribution Protocol#133543
• TRIS: A Tri-Layer Retrieval Integrity Sieve Against Knowledge Poisoning#627638
• The civil liability of the Judiciary with regard to court data leaks under the General Data Protection Law#1177075