Pith. sign in

REVIEW 3 major objections 3 minor 61 references

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

T0 review · 3 major / 3 minor · reviewed 2026-08-04 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Parquet decoding can be moved onto a SmartNIC in the network datapath, hiding the scan cost and nearly doubling DuckDB query throughput.

desk verdict A real, well-integrated FPGA Parquet decoder for DuckDB that nearly doubles throughput on its supported subset — just don't let the abstract oversell the coverage. read the letter →

arxiv 2608.02268 v1 pith:7NVTPOAN submitted 2026-08-03 cs.DB cs.AR

Jonas Dann , Luca Tagliavini , Gustavo Alonso This is my paper · ORCID
classification cs.DBcs.AR
keywords SmartNICParquetdecodinghardwareaccelerationFPGADuckDBquerythroughputclouddatabasedatapathoffloading
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that the CPU cost of decoding Parquet files—often about half of query runtime in cloud data warehouses—can be hidden by doing the decoding on a SmartNIC placed between object storage and the database. Oasis decompresses and decodes column chunks as they stream through the network, so the CPU receives already-decoded data and the scan overlaps with the rest of the query. In the best measured case, this almost doubles DuckDB's TPC-H query throughput and lets eight worker threads match the performance of sixteen threads decoding on the CPU. The supported subset is Snappy-compressed, non-nested, non-null fixed-width columns, which the authors argue covers the encodings real-world Parquet writers actually use.

What carries the argument

The central object is the Oasis column-chunk decoder pipeline: a page-header parser, a dual-issue 16-byte Snappy decompressor, a hybrid RLE/BPE run decoder, and a type-aware dictionary that maps encoded identifiers back to 32- or 64-bit values. The pipeline decodes at cache-line granularity as data streams from the network port, with a software abstraction layer scheduling independent column chunks onto a fixed number of hardware decoders and returning result futures to DuckDB worker threads.

What would settle it

Run Oasis against a benchmark of production Parquet files that are gzip/zstd-compressed or contain many string, nested, and nullable columns. If the CPU fallback decodes more than a small fraction of the bytes, the end-to-end throughput will drift back toward the CPU baseline. A second check: measure throughput with a copy-heavy table on a PCIe 5 or CXL link; if the PCIe interconnect is the binding constraint, the throughput should jump accordingly.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes that a hardware column-chunk decoder pipeline can decode Parquet at line rate in the datapath. Each pipeline parses Thrift page headers, decompresses Snappy, decodes plain, dictionary, and hybrid RLE/BPE runs, and resolves dictionary identifiers through a type-aware dictionary, writing decoded values into pre-allocated host buffers with zero-copy handoff. Because column chunks are self-contained, independent chunks are processed in parallel by multiple decoder instances, and a software abstraction layer schedules jobs from an unbounded number of worker threads onto a fixed number of hardware streams. The result is that scanning remote Parquet files cos

Load-bearing premise

The whole benefit rests on real-world Parquet files being mostly Snappy-compressed, non-nested, non-null, fixed-width columns with plain, dictionary, and hybrid RLE/BPE encodings; if files are dominated by strings, other compressions, nesting, or nulls, the CPU still pays most of the decode cost.

Editorial extensions

If this is right

  • The decode cost of Parquet scans can be removed from the CPU entirely for the supported column subset, so cores spend their time on query processing rather than decompression.
  • Oasis with four hardware decoders and eight DuckDB worker threads matches the CPU baseline's throughput at sixteen threads, a near doubling in the best case.
  • Scaling to more decoders is possible—the FPGA design uses under half the chip's resources—and the remaining bottlenecks are the PCIe interconnect and, for low-encoding-ratio columns, the Snappy decompressor itself.
  • The same pipeline can be extended to string columns by adding a variable-length dictionary, and to other compression schemes with a light wrapper around a different decompressor.
  • Pushing filters down into the datapath would reduce the volume of decoded data crossing PCIe, potentially making remote Parquet scans cost no more than in-memory scans.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The 'hidden decode cost' claim is conditional on real files matching the supported subset; if production Parquet contains substantial gzip/zstd-compressed, string, nested, or nullable data, the CPU fallback path would still pay a large share of the original tax—the paper's TPC-H results show string decoding and CPU filters still consume roughly 15% of total runtime each.
  • By placing decoding in the network path rather than in the storage or the CPU, the architecture implies a reshaping of the cloud data stack where the network turns storage formats into query-ready columns; the same placement could be tested for other formats like Arrow or JSON.
  • A straightforward experiment would add a gzip/zstd decompressor and measure whether the throughput gains survive the compression schemes more common in very large lakes; the paper's own claims suggest this is a wrapper, not a redesign.
  • The type-aware dictionary's deduplicator is designed for Zipf-skewed identifier streams, so adversarial or uniform high-cardinality data may not reach the same throughput—a boundary worth probing if Oasis is deployed on arbitrary user files.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 3 minor

Summary. The paper presents Oasis, a SmartNIC/FPGA-based system that decodes Parquet column chunks in the network datapath between object storage and a database host. The hardware design includes a widened dual-issue Snappy decompressor, a hybrid RLE/BPE run decoder, and a type-aware dictionary; the software layer provides asynchronous job scheduling and zero-copy buffer handoff, integrated into DuckDB as a table function. The evaluation uses TPC-H SF30 data and reports microbenchmark throughput for the hardware components, end-to-end per-query scan runtime, a multi-stream query throughput benchmark, and decoder utilization. The headline result is that Oasis nearly doubles DuckDB query throughput at 8 worker threads and hides the scan behind query execution for many queries, with residual CPU costs for string decoding and pushed-down filters.

Significance. If the claims hold, Oasis is a substantial systems contribution: it combines a custom hardware Parquet decoder, a software abstraction layer, and a real database integration, with open-source artifacts and an honest disclosure of current limitations. The microbenchmarks are carefully designed to isolate the effects of datapath width, dual-issue copies, deduplication, and value width. The end-to-end integration with DuckDB is non-trivial and the reported speedups are large. However, the evaluated scope is narrower than the title and abstract suggest: the hardware only covers Snappy-compressed, non-null, fixed-width 32/64-bit columns, and the end-to-end results are limited to DuckDB-written files. This scoping gap is load-bearing for the central claim and needs to be addressed either by additional experiments or by explicitly revised claims.

major comments (3)
  1. [Abstract, §4.5, §6.3, §8] The paper's central claim — 'Oasis hides the cost of Parquet decoding in the datapath' (Abstract; §8) — is supported only for a narrow subset of Parquet files. §4.5 limits the hardware to Snappy-compressed, non-null, non-nested, fixed-width 32/64-bit columns with plain/dictionary/hybrid encodings. The end-to-end evaluation (§6.3) uses only DuckDB-written, Snappy-compressed TPC-H files; Arrow-written files were tried but not reported (§6.1). The paper's own aggregate shows that ~15% of total query runtime remains in CPU string decoding and ~15% in CPU-side filters (§6.3.1). As written, the headline overstates the measured system. Please either (a) add end-to-end results on Arrow-written files, on at least one zstd/gzip-compressed file, and on a nullable or string-heavy schema, or (b) explicitly scope the abstract and §8 to 'Snappy-compressed fixed-width columns in DuckDB-written Parquet f
  2. [§4.5, §6.2.2] The generality argument for encoding coverage is not accompanied by evidence for compression coverage. §4.5 cites [31] for the claim that writers 'effectively exclusively use these encodings,' but [31] is about encodings, not compression schemes. No data supports the Snappy-only choice; gzip/zstd are common in data lakes and would bypass the accelerators entirely. Additionally, §6.2.2 states the design is 'well tuned' for the DuckDB writer (256-value BPE blocks, RLE threshold 4, 100 MiB pages, 122,880-row groups). These parameters differ in other writers (e.g., Arrow), so even within Snappy the decoder's performance on non-DuckDB files is unmeasured. A concrete test would be to run the microbenchmarks with Arrow writer parameters, or at minimum to state the parameter range the decoder can tolerate.
  3. [§6.1] The exclusion of Arrow-written files is not justified by the stated reason. 'Those achieve worse overall query throughput in DuckDB because Arrow's default row groups ... yield far less parallelism' compares absolute throughput. The relevant question for the Oasis claim is the relative speedup versus the DuckDB Parquet baseline on the same Arrow files. Larger row groups may reduce the number of decodable column chunks and change prefetching behavior, so Oasis's benefit could be larger or smaller. Please report the Arrow-file comparison or clearly state that all end-to-end results are limited to DuckDB-produced files.
minor comments (3)
  1. [§6.3.1] Each measurement is reported as the mean of three runs, but no variance, standard deviation, or confidence interval is given for Figure 12 or Figure 13. For the headline 'almost double' throughput claim, a min/max range or error bars would help rule out system noise as a confound.
  2. [§4.3] The notation '1 Mi' (twice in §4.3) should be '1 MiB' for consistency with the rest of the paper.
  3. [§6.4] The phrase 'write German string structs [37]' is unclear; [37] is the Umbra paper, so this likely should read 'Umbra-style string structs'.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the central result is a direct measured throughput comparison against DuckDB's own Parquet baseline; self-cited components are build infrastructure, not load-bearing derivation inputs.

full rationale

The paper's central claim is empirical, not derived: Oasis is built and measured end-to-end against DuckDB's native Parquet scan on the same TPC-H files (§6.3), and the reported 'almost doubling' of throughput is a measured outcome rather than a quantity implied by any fitted parameter. No step reduces by construction to its inputs. The hardware is indeed tuned to DuckDB's writer defaults (e.g., §4.3 and §6.2.2 mention RLE run threshold 4 and 256-value BPE blocks), but this is a design choice made before measurement, not a parameter fitted to the evaluation data and then called a prediction. The paper also explicitly scopes its supported subset in §4.5 (no strings, Snappy only, non-nested, non-null) and, in §6.3.1, reports residual CPU costs for string decoding and pushed-down filters; this is an honest scope limitation, not circularity. Self-citations to SCENIC, Coyote v2, RoCE BALBOA, and libSTF/GraphScale describe implementation infrastructure used to build the prototype; they are not invoked as proof of the performance claim, and the evaluation is an independent external benchmark against DuckDB rather than a consequence of those citations. The only cited study about real-world Parquet encodings ([31]) is not authored by the Oasis authors and is used to justify encoding coverage, not to derive the throughput result. Overall, the derivation chain is self-contained as an experimental systems paper, with no circular step.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

The central result is empirical: a hardware/software system measured against DuckDB. The load-bearing assumptions are about Parquet format coverage and the deployment model (RDMA vs. object storage), not about fitted numerical parameters. The listed free parameters are experimental configurations and hardware sizing choices, not values fit to make a derivation work.

free parameters (4)
  • num_hardware_decoders = 4
    Number of column-chunk decoder instances instantiated in the FPGA design; chosen to fit the Alveo U55C and drives the throughput scaling results (§6.1, Table 1). This is a design choice, not fitted to data.
  • prefetch_depth = 2
    Configurable number of row groups kept in flight in read_oasis(); set to 2 for the decoder-utilization experiment (§6.3.3). A tunable that affects measured utilization, not a fitted constant.
  • worker_threads = 8
    DuckDB worker thread count used for the per-query runtime experiments (§6.3.1). Chosen as a representative configuration; different thread counts change the absolute throughput numbers.
  • dictionary_size_cap = 2 MiB (2^19 32-bit entries)
    Hardware dictionary capacity chosen to exceed the ~1 MiB dictionaries produced by real-world writers (§4.3). Affects resource usage and the bit-width range of identifiers; a design parameter, not fitted.
assumptions (4)
  • domain assumption In practice, Parquet writers exclusively use plain, dictionary, and hybrid RLE/BPE encodings, and Snappy compression is the dominant scheme.
    Justifies restricting the hardware decoder to this subset of the Parquet standard (§2.1, §4.5); supported by a citation to a single study [31]. If other encodings or compression schemes (e.g., zstd, gzip) are widespread in production data lakes, Oasis's coverage claim is weaker.
  • domain assumption Real-world Parquet writers cap page value counts around 1 Mi and dictionaries at ~1 MiB, allowing the run decoder and dictionary to use narrow (19/21-bit) signals.
    Used in §4.3 to shrink hardware resources; the paper states 'neither constraint sacrifices generality in practice' but does not verify against all writers or all Parquet files.
  • domain assumption The target workload can be modeled as non-nested, non-null relational tables with fixed-width 32/64-bit columns; string columns are handled by CPU fallback.
    Explicitly stated in §4.5 (Limitations) and §5.2.1. The TPC-H evaluation still includes string columns via CPU decoding, so the central 'hidden decode cost' claim applies only to the fixed-width subset.
  • domain assumption RDMA reads from a remote memory region accurately model cloud object storage access patterns.
    The end-to-end experiments use an RDMA server rather than S3/HTTP (§5.2.2); S3 support is deferred to future work. Cloud object storage has different latency and API characteristics, so the measured overlap may change in a real deployment.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Oasis: Hiding the Cost of Querying Parquet Files in the Datapath." pith.science (2026). https://pith.science/paper/7NVTPOAN

@misc{pith2026260802268,
  author       = {Pith},
  title        = {Pith review of: Oasis: Hiding the Cost of Querying Parquet Files in the Datapath},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7NVTPOAN}},
  note         = {Machine review of arXiv:2608.02268}
}
read the original 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.

Figures

Figures reproduced from arXiv: 2608.02268 by the authors.

Figure 1
Figure 1. TPC-H (scale factor 30, four streams) throughput [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Parquet compressed, columnar file format horizon [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Oasis SmartNIC architecture and detailed hardware column-chunk decoder pipeline. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: Original 8 byte-wide Snappy decompressor and our [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Type-aware dictionary with 8 banks and a detailed [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Control flow: worker threads submit decoding [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: TPC-H benchmark query 6 using the Oasis exten [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Snappy decompressor throughput and speedup for [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: Hybrid run decoder throughput in billions of values [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 11
Figure 11. Figure 11: TPC-H (scale factor 30) lineitem table per-column [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]
Figure 12
Figure 12. Figure 12: TPC-H (scale factor 30) benchmark per-query runtime in seconds comparing the baseline DuckDB Parquet extension [PITH_FULL_IMAGE:figures/full_fig_p011_12.png]
Figure 13
Figure 13. Figure 13: TPC-H (scale factor 30, four streams) throughput [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

61 extracted references · 4 canonical work pages

  1. [31]

    Si Jun Kwon, Zsolt István, Daniel Ritter, Norman May, and Christian Faerber

  2. [1]

    Azim Afroozeh and Peter Boncz. 2025. The FastLanes File Format.Proc. VLDB Endow.18, 11 (2025), 4629–4643. doi:10.14778/3749646.3749718

    arXiv 2025

  3. [2]

    Alibaba Cloud Community. 2022. A Detailed Explanation about Alibaba Cloud CIPU. https://www.alibabacloud.com/blog/a-detailed-explanation-about- alibaba-cloud-cipu_599183

    2022

  4. [3]

    2022.The Components of the Nitro System (The Security Design of the A WS Nitro System Whitepaper)

    Amazon Web Services. 2022.The Components of the Nitro System (The Security Design of the A WS Nitro System Whitepaper). Technical Report. Amazon Web Services. https://docs.aws.amazon.com/whitepapers/latest/security-design-of- aws-nitro-system/the-components-of-the-nitro-system.html Accessed: 2026- 04-15

    2022

  5. [4]

    Apache Software Foundation. 2025. Apache Parquet Format Specification. https: //parquet.apache.org/. Accessed: 2026-04-30

    2025

  6. [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 Polychro- niou, Foyzur Rahman, Gaurav Saxena, Gokul Soundara...

    arXiv 2022

  7. [6]

    Daniel Bauer, Luis Garcés-Erice, Deepak Majeti, Zoltan Arnold Nagy, Sean Rooney, Greg Kimball, Devavret Makkar, Todd Mostak, and Karthikeyan Natara- jan. 2026. Accelerating Presto with GPUs.CoRRabs/2606.24647 (2026). doi:10.48550/ARXIV.2606.24647

    work page Pith review arXiv doi:10.48550/arxiv.2606.24647 2026

  8. [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

    2018

Show all 61 references
  1. [8]

    Monica Chiosa, Fabio Maschi, Ingo Müller, Gustavo Alonso, and Norman May

  2. [10]

    Jonas Dann, Daniel Ritter, and Holger Fröning. 2022. GraphScale: Scalable Bandwidth-Efficient Graph Processing on FPGAs. In32nd International Con- ference on Field-Programmable Logic and Applications, FPL 2022, Belfast, United Kingdom, August 29 - Sept. 2, 2022. IEEE, 24–32. d...

    2022

  3. [11]

    Jonas Dann, Royden Wagner, Daniel Ritter, Christian Faerber, and Holger Fröning

  4. [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 Data- Intensive Applications. InCompanion of the 2024 International Conference on Management of Data, SIGMOD/PODS 2024, Santiago, Ch...

    2024

  5. [13]

    PipeJSON: Parsing JSON at Line Speed on FPGAs. InDaMoN. ACM, 3:1–3:7. doi:10.1145/3533737.3535094

  6. [14]

    Caulfield, Eric S

    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, J...

  7. [15]

    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

    2020 doi

  8. [16]

    Dimitrios Giouroukis, Dwi P. A. Nugroho, Varun Pandey, Steffen Zeuch, and Volker Markl. 2025. Analyzing Near-Network Hardware Acceleration with Co- Processing on DPUs.Proc. VLDB Endow.18, 13 (2025), 5689–5702. doi:10.14778/ 3773731.3773743

    2025

  9. [17]

    Google LLC. [n. d.]. Snappy: A fast compressor/decompressor. https://github. com/google/snappy. Accessed: 2026-07-24

    2026

  10. [19]

    Bernstein, Jialin Li, and Qizhen Zhang

    Jason Hu, Philip A. Bernstein, Jialin Li, and Qizhen Zhang. 2025. DPDPU: Data Processing with DPUs. InCIDR. www.cidrdb.org

    2025

  11. [20]

    Gui Huang, Xuntao Cheng, Jianying Wang, Yujie Wang, Dengcheng He, Tiey- ing Zhang, Feifei Li, Sheng Wang, Wei Cao, and Qiang Li. 2019. X-Engine: An Optimized Storage Engine for Large-scale E-commerce Transaction Processing. InProceedings of the 2019 International Conference on...

    2019

  12. [21]

    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.CoRRabs/2507.20412 (2025). doi:10.48550/ARXIV.2507. 20412

    2025 doi arXiv

  13. [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 wi...

    2025

  14. [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

    2025

  15. [24]

    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 Chaud- huri, Johannes Gehrke, Raghu Ramakrishnan, Lidong...

  16. [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

    2018

  17. [26]

    Kfoury, Samia Choueiri, Ali Mazloum, Ali AlSabeh, Jose Gomez, and Jorge Crichigno

    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 Access12 (2024), 107297–107336. doi:10.1109/ACCESS.2024.3437203

    2024

  18. [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

    2020

  19. [28]

    Sagar Karandikar, Chris Leary, Chris Kennelly, Jerry Zhao, Dinesh Parimi, Borivoje Nikolic, Krste Asanovic, and Parthasarathy Ranganathan. 2021. A Hardware Accelerator for Protocol Buffers. InMICRO ’21: 54th Annual IEEE/ACM International Symposium on Microarchitecture, Virtual...

    2021

  20. [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. Data2, 6 (2024), 238:1–238:27. doi:10.1145/ 3698813

    2024

  21. [30]

    Maximilian Kuschewski, David Sauerwein, Adnan Alhomssi, and Viktor Leis

  22. [32]

    Simon Kuenzer, Vlad-Andrei Badoiu, Hugo Lefeuvre, Sharan Santhanam, Alexan- der 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, speciali...

    2021

  23. [33]

    Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shivaku- mar, Matt Tolton, and Theo Vassilakis. 2011. Dremel: interactive analysis of web- scale datasets.Commun. ACM54, 6 (2011), 114–123. doi:10.1145/1953122.1953148

    2011

  24. [34]

    Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shiv- akumar, Matt Tolton, Theo Vassilakis, Hossein Ahmadi, Dan Delorey, Slava Min, Mosha Pasumansky, and Jeff Shute. 2020. Dremel: A Decade of Interac- tive SQL Analysis at Web Scale.Proc. VLDB Endow.13, 12 ...

    2020

  25. [35]

    Mahmoud Mohsen, Norman May, Christian Färber, and David Broneske. 2020. FPGA-Accelerated compression of integer vectors. In16th International Workshop 13 on Data Management on New Hardware, DaMoN 2020, Portland, Oregon, USA, June 15, 2020. ACM, 9:1–9:10. doi:10.1145/3399666.3399932

    2020

  26. [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

    2011

  27. [37]

    InProceedings of the 22nd International Workshop on Data Management on New Hardware, DaMoN 2026, Bengaluru, India, 31 May 2026- 5 June 2026

    Efficient Parquet Parsing on FPGAs. InProceedings 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

    2026

  28. [38]

    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

    2024

  29. [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. InFPT. IEEE, 1–9. doi:10.1109/ICFPT52863.2021.9609833

    2021

  30. [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. InFPT. IEEE, 281–286. doi:10.1109/ ICFPT51103.2020.00048

    2020 arXiv

  31. [41]

    Mark Raasveldt and Hannes Mühleisen. 2019. DuckDB: an Embeddable Analytical Database. InSIGMOD. ACM, 1981–1984. doi:10.1145/3299869.3320212

    2019

  32. [42]

    Benjamin Ramhorst, Maximilian Jakob Heer, Luhao Liu, Heejae Kim, Jonas Dann, Jin-Soo Kim, and Gustavo Alonso. 2026. SCENIC: Stream Computation-Enhanced SmartNIC.CoRRabs/2604.15128 (2026). doi:10.48550/arXiv.2604.15128

    2026 doi arXiv

  33. [43]

    Thomas Neumann and Michael J. Freitag. 2020. Umbra: A Disk-Based Sys- tem with In-Memory Performance. In10th Conference on Innovative Data Sys- tems Research, CIDR 2020, Amsterdam, The Netherlands, January 12-15, 2020, Online Proceedings. www.cidrdb.org. http://cidrdb.org/cidr...

    2020

  34. [44]

    2012.A Technical Overview of the Oracle Exadata Data- base Machine and Exadata Storage Server

    Oracle Corporation. 2012.A Technical Overview of the Oracle Exadata Data- base Machine and Exadata Storage Server. White Paper. Oracle Corpora- tion. https://www.oracle.com/technetwork/server-storage/engineered-systems/ exadata/dbmachine-x3-twp-1867467.pdf

    2012

  35. [45]

    2007.Thrift: Scalable Cross- Language Services Implementation

    Mark Slee, Aditya Agarwal, and Marc Kwiatkowski. 2007.Thrift: Scalable Cross- Language Services Implementation. Technical Report. Facebook. https://thrift. apache.org/static/files/thrift-20070401.pdf

    2007

  36. [46]

    Jan Vincent Szlang, Sebastian Breß, Sebastian Cattes, Jonathan Dees, Florian Funke, Max Heimel, Michel Oleynik, Ismail Oukid, and Tobias Maltenberger

  37. [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:1...

    2024

  38. [48]

    Alexander van Renen and Viktor Leis. 2023. Cloud Analytics Benchmark.Proc. VLDB Endow.16, 6 (2023), 1413–1425. doi:10.14778/3583140.3583156

    2023

  39. [49]

    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. InSOSP. ACM, 639–654. doi:10.1145/3731569.3764845

    2025

  40. [50]

    Alice Rey, Michael Freitag, and Thomas Neumann. 2023. Seamless Integration of Parquet Files into Data Processing. InDatenbanksysteme für Business, Technologie und Web (BTW 2023), 20. Fachtagung des GI-Fachbereichs „Datenbanken und Informationssysteme" (DBIS), 06.-10, März 2023...

    2023 doi

  41. [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. Data3, 3 (2025), 138:1–138:27. doi:10.1145/3725275

    2025 doi

  42. [52]

    Woicik, Abdurrahman Ghanem, Marco Serafini, Ashraf Aboulnaga, and Michael Stonebraker

    Xiangyao Yu, Matt Youill, Matthew E. Woicik, Abdurrahman Ghanem, Marco Serafini, Ashraf Aboulnaga, and Michael Stonebraker. 2020. PushdownDB: Ac- celerating a DBMS Using S3 Computation. InICDE. IEEE, 1802–1805. doi:10. 1109/ICDE48307.2020.00174

    2020

  43. [53]

    Matei Zaharia, Ali Ghodsi, Reynold Xin, and Michael Armbrust. 2021. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Ad- vanced Analytics. In11th Conference on Innovative Data Systems Research, CIDR 2021, Virtual Event, January 11-15, 2021, Online ...

    2021

  44. [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

    2023

  45. [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. In18th USENIX Conference on File and Storage Technologi...

    2020

  46. [56]

    Midhul Vuppalapati, Justin Miron, Rachit Agarwal, Dan Truong, Ashish Motivala, and Thierry Cruanes. 2020. Building An Elastic Query Engine on Disaggregated Storage. InNSDI. USENIX Association, 449–462

    2020

  47. [57]

    Yifei Yang, Xiangyao Yu, Marco Serafini, Ashraf Aboulnaga, and Michael Stone- braker. 2024. FlexpushdownDB: rethinking computation pushdown for cloud OLAP DBMSs.VLDB J.33, 5 (2024), 1643–1670. doi:10.1007/s00778-024-00867-8

    2024 doi

  48. [63]

    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 14

    2025

  49. [2018]

    Azure Accelerated Networking: SmartNICs in the Public Cloud. InNSDI. USENIX Association, 51–66

  50. [2022]

    Hardware Acceleration of Compression and Encryption in SAP HANA. Proc. VLDB Endow.15, 12 (2022), 3277–3291. doi:10.14778/3554821.3554822

    2022

  51. [2023]

    ACM Manag

    BtrBlocks: Efficient Columnar Compression for Data Lakes.Proc. ACM Manag. Data1, 2 (2023), 118:1–118:26. doi:10.1145/3589263

    2023 doi

  52. [2025]

    VLDB Endow.18, 12 (2025), 5126–5138

    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

    2025

  53. [2026]

    InCompanion of the International Conference on Management of Data, SIGMOD Companion 2026, Bengaluru, India, 31 May 2026 - 5 June 2026

    CoddSpeed: Hardware Accelerated Query Processing in Microsoft Fabric. InCompanion 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

    2026

Pith tools

Reviewed August 4, 2026 · model on record in the stance chip above.