Compute Moves to the Data Again: GPU Acceleration at the Storage Layer

Open the profile on your slowest nightly job and read it honestly. On most platforms we are handed, the CPU is busy for a fraction of the wall clock. The rest is bytes in motion — pulled off object storage, decompressed, decoded from Parquet into memory, serialised, shuffled across the network, deserialised, and then finally touched by the arithmetic anybody actually asked for. The compute is not the expensive part. The commute is.

The industry rediscovers this roughly every five years and gives it a new name. This month it has a new one again: on 16 July 2026, NetApp announced it had acquired DataPelago, a company whose engine does GPU-accelerated data processing aligned to the storage layer rather than in a separate compute cluster you feed by copying everything to it. DataPelago becomes a wholly owned subsidiary. The price was not disclosed; Blocks & Files reports the company had raised over $75 million since being founded in 2021, and came out of stealth in October 2024.

The strategic logic is sound and worth taking seriously. The purchasing logic — that you should go buy accelerated silicon for your own pipeline — is much weaker than the announcement implies, and the gap between those two things is where a lot of budget is about to disappear.

The data-movement tax, itemised#

Nobody puts a line item for byte-shuffling in the platform budget, which is precisely why it grows. It shows up in four places.

• Egress and cross-zone transfer. Every hop that crosses an availability zone, a region, or a cloud boundary is metered. Pipelines that were designed once and never re-read tend to cross those boundaries several times per run.
• Serialisation and format conversion. Parquet to Arrow to JVM objects to Arrow again to whatever the next stage wants. Each conversion is CPU time and memory pressure spent producing zero new information.
• Network hops and shuffle. A join that spills into a shuffle moves the working set across the fabric. Shuffle is usually the single largest term in a slow distributed query, and it is almost never the term teams attack first.
• Decompression and decode. Zstd or Snappy over columnar files buys you cheaper storage and cheaper transfer at the cost of CPU at read time. That trade is usually correct, and it is still a cost you should be able to name.

Measuring this in your own system is not exotic. Take one representative job and get four numbers: bytes read from storage, bytes shuffled, bytes returned to the client, and CPU-seconds spent in scan and decode versus everything else. Spark exposes most of this in the stage metrics; Trino gives it to you per-operator in the query plan; ClickHouse will tell you rows and bytes read per query in system.query_log. Then compute the ratio that matters: bytes read divided by bytes your query actually needed to answer the question. If you read 400 GB to produce a 2 MB aggregate, no accelerator on earth is your primary problem. Your read amplification is.

What DataPelago actually built#

Worth being precise, because “GPU database” is a phrase that has meant six different things over a decade. DataPelago’s engine, Nucleus, sits between existing query engines and the hardware. It takes a physical plan from Spark, Trino, or similar, decomposes it into operators, and dispatches each operator to whichever silicon suits it — CPU, GPU, or FPGA. Blocks & Files describes a three-layer design (a plug-in layer for the engine, a mapping layer to heterogeneous compute, and an instruction set that abstracts the target hardware) built on open components including Apache Gluten, Velox, and Substrait.

That last detail is the interesting one. Gluten — which graduated to an Apache top-level project in March 2026 — already does the unglamorous half of this work: it converts a Spark physical plan to Substrait and hands it to a native C++ backend so the JVM stops being the bottleneck. Substrait is the plan interchange format; Velox is the execution library. A large part of the “breakthrough accelerated engine” category is, structurally, this open stack plus a vendor’s operator kernels and a scheduler that knows which kernel goes where.

The performance claims deserve the same precision. NetApp’s release cites up to 10x faster processing and up to 80% lower infrastructure cost. DataPelago’s own August 2025 benchmark announcement is more specific and more useful: up to 10.5x faster project operations, 10.1x faster filters, and 4.3x faster aggregates against Nvidia’s cuDF, with larger multiples on variable-length string work. Note two things. Every number is an “up to” against a single competitor library at the operator level, and the hardware configuration, dataset shape, and test conditions are not published alongside them. Operator microbenchmarks are real engineering signal. They are not a forecast of your end-to-end job time, because your end-to-end job time is dominated by the terms the microbenchmark excluded.

The idea is thirty years old and keeps being right#

This is not a new insight, and treating it as one is how teams end up buying the fourth implementation of something they already own.

Columnar formats were the first version of the argument: store data so a query touching three of ninety columns reads three columns. Predicate pushdown was the second: send the WHERE clause down to the reader so row groups whose min/max statistics cannot possibly match are never decompressed. Partition pruning was the third, and remains the highest-leverage optimisation available to most teams. Then storage-side filtering went over the wire — AWS shipped S3 Select and wired it into Presto and Hive so projection and predicate work happened inside the storage service and only matching bytes crossed the network. AWS has since stopped offering S3 Select to new customers and points people at Athena, S3 Object Lambda, or client-side filtering instead. The idea did not fail; the specific packaging did, mostly because it was constrained in the formats it handled.

Meanwhile the hardware community pursued the same goal from the other end. Computational storage — putting a processor on or beside the drive — has an SNIA standards effort behind it and roughly two decades of academic work. Its adoption problem was never the physics. It was that every vendor’s offload interface was different, so the interchangeability that makes an SSD an SSD disappeared the moment you depended on its compute. And GPU query engines have been shipped, acquired, and quietly wound down repeatedly since the mid-2010s.

The pattern is consistent: moving compute toward data is durably correct as a principle and historically fragile as a product, because it demands that a specialised layer stay compatible with a fast-moving open ecosystem above it. Buying it from a storage vendor with a large installed base is a genuinely better bet than the standalone attempts — that is the real thesis of this acquisition — but it does not change the physics of what wins.

Where the acceleration is real, and where it is a rounding error#

Storage-side and GPU acceleration wins decisively on a specific shape of work: wide scans over large columnar datasets with expensive per-row predicates, heavy string manipulation, regex, decompression, and vectorisable projections. Embedding preparation and feature extraction over a lake — the unglamorous bulk of AI implementation work — fits this profile well. So does log and telemetry search where the filter is selective but must be evaluated over everything.

It is a rounding error everywhere else, and “everywhere else” is where most enterprise pipelines live. A 10x faster filter recovers a few seconds of an eleven-minute job whose ten remaining minutes are a broadcast join that should have been a hash join, a missing partition predicate that turned a day’s read into a year’s, forty thousand 200 KB Parquet files whose metadata cost exceeds their content, or a SELECT * at the top of a view chain nobody has read since 2023. Accelerating the scan under a bad plan buys you a faster path to the same wall.

There is a second cost that never appears in the pitch: you now operate a specialised engine. Someone has to monitor it, patch it, reason about why it silently fell back to CPU on the one query that mattered, keep it compatible with your Spark or Trino upgrades, and be reachable at 3 a.m. when a kernel behaves differently on a new driver version. You have to hire for it, or accept that exactly one person understands it. For most teams that operational surface is a larger long-run expense than the compute it saves.

Fix the boring things first#

The honest sequence, in order, before anyone signs anything:

Partition on the column you actually filter by, and verify pruning is happening rather than assuming it. Compact small files until your average Parquet file is in the hundreds of megabytes. Sort within files on the predicate columns so min/max statistics become selective instead of decorative. Delete SELECT * from every view definition. Read the plans for your ten most expensive queries and fix the join strategies. Those five moves routinely deliver larger end-to-end improvements than any accelerator, cost nothing but attention, and — critically — make the accelerator worth more if you buy one later, because acceleration multiplies a good plan and merely subsidises a bad one.

This is the same discipline behind our own operational engine, which is built on ClickHouse and held to a sub-second query bar on live operational data. That bar is not met by exotic hardware. It is met by modelling the data for the questions users ask, keeping the read path narrow, and refusing to move bytes that no answer depends on.

The Data Platforms lesson generalises past analytics. Legacy ERP vendors trap data inside their own runtime, then sell you a reporting module to get it back out — the most expensive form of data movement there is, paid in licences instead of egress. When we build a Hospital Management System or a School ERP, the operational database is a queryable platform from day one, so an Operational Automation workflow or an AI feature reads directly from the system of record instead of shipping a nightly extract to somewhere it can finally be useful. ERP as a data platform with thoughtful UI on top, rather than a data prison with a reporting concession stand attached.

NetApp is right that the bottleneck is data movement. Just make sure the movement you eliminate is the movement you actually have.

---

Before you buy acceleration, measure how many bytes your pipeline reads that no answer depends on. Send us a query plan at /#contact.