Computational Storage
1. Overview
A. Definition
Computational Storage is an architecture that integrates compute resources (CPU cores, FPGA, or dedicated accelerators) inside or near a storage device (such as an SSD) so that data is processed directly where it resides (In-Storage Processing) rather than being pulled up to the host CPU in its entirety. It applies the idea of "bringing compute to data" to the storage tier, and the standards body SNIA defines it under the umbrella term CSx (Computational Storage device).
In traditional computing, storage was a passive medium that merely held data, and all computation was handled by the host CPU and memory. To run analysis or search, all the raw data on the device had to be read up over the PCIe bus and into system memory, after which only a tiny fraction was actually used and the rest discarded. As data grew to terabyte and petabyte scale, this "read-up-and-filter" model itself became a bottleneck. Computational storage finishes first-stage processing such as filtering, aggregation, compression, and encryption inside the device, and forwards only the result (a drastically reduced amount of data) to the host, thereby reducing both bus traffic and host load simultaneously. Representative commercial examples include Samsung's SmartSSD (with an embedded FPGA), ScaleFlux's transparent-compression CSD, and NGD Systems' ARM-core Newport.
B. Background and necessity
Three pressures converged behind the rise of computational storage. The first is the data movement bottleneck. NAND flash has very high internal bandwidth thanks to parallel channels and dies, but the PCIe/network bandwidth that carries data out to the host is comparatively narrow. For a query that scans hundreds of terabytes to extract only the matching 1%, moving the remaining 99% to the host is plainly wasteful. The second is the limit on CPU resources and power. In large data centers, simple repetitive tasks such as compression, encryption, and scanning eat up expensive host CPU cycles; offloading them to the cheap, data-adjacent compute inside the storage device frees the CPU for its proper application logic.
The third is the economics of scale-out. Because compute capacity grows together with each added storage device, throughput scales linearly with capacity, unlike the centralized model where computation concentrates on a single host CPU. In a distributed environment with thousands of storage nodes, pooling each node's idle compute amounts to enormous parallel processing power, which also aligns with maximizing data locality. As these three pressures combined, the "smart disk (Active Disk)" concept, once confined to the research stage, re-emerged as a practical architecture alongside the maturation of NVMe, FPGA, and high-density process technology.
In fact, the idea that "a storage device computes on its own" dates back to the late-1990s Active Disk and IDISK research. At the time, however, the in-disk compute performance was weak and there was no standard interface to the host, so it never reached commercialization. What has changed today is that ① SSD controllers have evolved to be multi-core and high-performance, ② process technology has matured enough to integrate FPGA and ARM into a drive, and ③ NVMe and SNIA have begun to provide vendor-neutral standards. In other words, computational storage is best understood not as a new idea but as a long-standing one that became feasible only when it met the maturation of hardware and standards.
C. Characteristics
The nature of computational storage is captured by the following three characteristics. They interlock and converge on a single principle: "do not move the data."
- Near-Data Processing: Placing compute resources close to the storage medium minimizes the distance data must travel. The source of the performance gain lies in using the storage device's high internal parallel bandwidth directly, free of host bus constraints.
- Data Reduction: Scan, filter, aggregation, and compression reduce the very amount of data forwarded to the upper tier. It is a technology with clear workload selectivity, where the larger the reduction ratio, the greater the benefit.
- Transparency and compatibility: Approaches that require no application change (such as transparent compression) coexist with approaches that explicitly push functions down via a standard API, so the burden of integrating with the existing storage stack is relatively low.
2. Architecture and components
The essence of computational storage lies in how closely the compute engine is coupled to the storage medium and how the host controls that computation. The former determines the amount of data movement and the latter determines development convenience and portability, so both axes must be viewed together to properly grasp the character of the architecture. The structural diagram below shows the difference in data flow between the traditional storage model and computational storage, along with the main components of the SNIA model.
flowchart LR
subgraph TRAD["Traditional storage model"]
H1["Host CPU/memory"]
D1["Passive storage device(SSD)"]
D1 -- "transfer all raw data(bottleneck)" --> H1
H1 -- "host performs filtering/aggregation" --> H1
end
subgraph CS["Computational storage(CSx)"]
H2["Host agent"]
subgraph DEV["Inside the storage device"]
ST["Storage medium(NAND)"]
CSE["Compute engine(CSE)"]
FDM["Device memory(FDM)"]
ST --- CSE
CSE --- FDM
end
H2 -- "compute request/small result" --> DEV
end
In the traditional model (left), the entire raw dataset travels up the bus, whereas in computational storage (right) the compute engine (CSE, Computational Storage Engine) finishes first-stage processing next to the storage medium, holds it in device memory (FDM, Function Data Memory), and returns only a small amount to the host. SNIA's Architecture and Programming Model v1.0 (approved in 2022) organized this ecosystem with standard terms: it distinguishes device types as the CSD (Computational Storage Drive) where storage and compute are one body, the CSP (Computational Storage Processor) that handles compute only without storage media, and the CSA (Computational Storage Array) that bundles multiple devices, and it defines the unit of work running on them as the CSF (Computational Storage Function).
A. Device types — CSD, CSP, CSA
The character of a device varies with how the compute resource and storage medium are combined. A CSD is the most common form, with NAND storage media and a compute engine together in a single drive, performing compression, search, and encryption on the data stored in that drive right in place. ScaleFlux transparently compressing block data the instant it is written, extending effective capacity and lifespan, is a representative example. A CSP provides compute capability only, with no storage medium of its own, taking on the role of processing data streams flowing in from the network or other storage devices. A CSA bundles multiple storage devices and compute resources into a single logical unit to distribute computation at the array level, extending the computational storage concept to large-scale storage arrays. In practice these are chosen and mixed according to where the workload's data resides (inside the device vs. an external stream).
This classification matters because where compute is placed determines the amount of data movement. If, as in a CSD, the compute unit is one body with the medium, data does not travel a single step out of the drive, whereas a compute unit separated from the medium like a CSP must first pull the data in, leaving that much movement. Thus a CSD is advantageous for repeatedly processing data resident on its own device, and a CSP for generically processing streams flowing in from multiple sources. A CSA combines the two at the array level, enabling a distributed design that scales capacity and compute linearly at the same time.
B. Compute engine implementation — fixed and programmable
What the compute resource placed in the storage device is implemented with is also an important branch. A fixed-function engine bakes frequently used operations such as compression, encryption, and deduplication into dedicated hardware blocks for top efficiency but no flexibility. A programmable engine splits again into two: FPGA-based ones can reconfigure circuits to hold diverse acceleration logic, as adopted by Samsung SmartSSD, while embedded-CPU (mostly ARM) based ones can run a general-purpose environment such as Linux inside the storage device to execute ordinary programs, as chosen by NGD Newport. The former's strength is performance and power efficiency, the latter's is generality and development convenience. This choice forms the classic "efficiency vs. flexibility" trade-off.
A constraint easily overlooked here is the power and thermal budget. A typical NVMe SSD's power consumption ranges roughly from a few to a few tens of watts per drive depending on form factor, and this budget was originally meant for the flash controller and NAND operation. The compute engine must share power within this limited budget, so one cannot expect the high-performance computation of a host CPU that uses tens to hundreds of watts. The reason an FPGA type excels in performance per watt on specific kernels lies precisely in this constraint, while a general-purpose ARM type is flexible but lags in absolute performance. Ultimately, the choice of implementation is the answer to the question "which operation, at what power budget, and how often to be changed."
C. Core components — CSE, CSEE, CSF, device memory
The SNIA model decomposes the device interior into several standard blocks. The CSE (Computational Storage Engine) is the processing resource that actually performs computation—an FPGA, ARM core, or dedicated ASIC falls here. The execution environment in which computation runs on top of the CSE is called the CSEE (Computational Storage Engine Environment), which provides the base for loading and executing functions, like an embedded operating system or an FPGA bitstream loader. A single unit of work performed on top of it is the CSF (Computational Storage Function), where concrete operations such as compression, search, and encryption are defined as CSFs that are downloaded from the host or pre-loaded.
Computation needs a workspace, so the device holds separate memory. The region where the host exchanges compute input and output is the FDM (Function Data Memory), and the part of it allocated exclusively to a particular CSF is called the AFDM (Allocated Function Data Memory). The host moves data from the storage medium into the FDM, executes the CSF, and reads the result back from the FDM. By separating engine (CSE), execution environment (CSEE), function (CSF), and working memory (FDM/AFDM) into standard terms this way, host software can handle devices with the same model even across vendors. This is the decisive difference that separates today's computational storage from the fragmented intelligent-storage research of the past.
D. Offloading flow and programming model
The process by which computational storage actually handles work can be summarized as "the host dispatches a function and the device executes it next to the data." The procedure diagram below shows the flow when a large table scan is delegated (offloaded) to computational storage.
flowchart TB
P1["Host: identify data-intensive op(e.g. WHERE scan)"]
P2["Download/activate CSF to device"]
P3["Host agent issues compute request(specify target range)"]
P4["Compute engine reads medium data directly and filters"]
P5["Load result into device memory(FDM)"]
P6["Return only small matching result to host"]
P1 --> P2 --> P3 --> P4 --> P5 --> P6
The crux is steps 4–6. The vast raw table does not leave the storage device; the compute engine reads directly from NAND and evaluates the conditions, so PCIe transfer volume drops drastically. What returns to the host is only the small number of rows meeting the conditions. The step-2 CSF download, done once, is reused repeatedly and thus pays back more than its initial cost. Making this possible requires a standard interface, for which SNIA separately defined the Computational Storage API v1.0 bridging applications and CSx, and the NVMe camp also prepared the Computational Programs command set specification expressing computation as commands to standardize device control.
How to push compute logic down to the device safely is also an important design element. Running an arbitrary binary directly on the device carries a high risk of device damage and data leakage, so recent research uses sandbox execution models such as eBPF or WebAssembly (Wasm) as offloading means. eBPF provides a verifier model that safely runs small, verified programs in the kernel, and Wasm provides highly portable bytecode and isolated execution, respectively opening a path to safely load and execute the same compute logic even across different device vendors. This shows that computational storage is evolving beyond mere hardware acceleration into a general-purpose offloading platform with built-in security.
3. Type comparison and application cases
Even the same computational storage differs in implementation and target workload. The table below compares representative approaches, with the reason for each choice explained in prose afterward.
| Category | Compute resource | Main use | Strength | Representative case |
|---|---|---|---|---|
| Fixed CSD | dedicated HW block | transparent compression/encryption | top efficiency, seamless integration | ScaleFlux CSD |
| FPGA CSD | reconfigurable logic | DB scan, video transcode | flexible acceleration, high performance | Samsung SmartSSD |
| ARM CSD | embedded CPU | general preprocessing, AI | generality, dev convenience | NGD Newport |
| CSP | external accelerator | stream processing | scaling decoupled from medium | Eideticom NoLoad |
The reason an FPGA type targets database scans is that an analytic query is a typical data-intensive task that sweeps vast data to pull out a tiny few. In Samsung's and database vendors' benchmarks, offloading scan and filter to SmartSSD has been reported to greatly reduce the processing time of certain queries while simultaneously lowering host CPU utilization and power consumption. By contrast, a fixed type like ScaleFlux concentrating on transparent compression is because compression applies universally to every block write, so baking it into a dedicated circuit gives the best performance, power efficiency, and reliability and requires no application change at all. In other words, the optimal implementation diverges depending on whether the workload is "variable computation that differs per query" or "fixed computation that always applies."
Looking at the effect concretely, a transparent-compression CSD gains roughly 2–4x effective capacity expansion depending on data characteristics, along with extended flash lifespan from reduced write volume, at the same time. Because compression/decompression is processed at line rate inside the device, the host need not be aware of whether compression is happening. In database scan offloading, the data volume coming up over PCIe shrinks in proportion to selectivity, so a query with 1% selectivity theoretically reduces bus traffic to about 1/100, saving outright the cycles the host CPU spent on decoding and comparison. Other major application points include real-time compression/transcoding of large logs and video, offloading erasure-coding parity computation in distributed file systems, and data preprocessing (decode, resize) before AI training, all sharing the principle that "the smaller the amount to send out relative to the amount read, the greater the benefit."
4. Comparison with similar concepts
Within the broad current of data-centric computing, computational storage is often confused with PIM and in-memory databases, so the boundaries need to be made clear. PIM (Processing-in-Memory) places the compute unit inside volatile memory (DRAM) to target the memory bandwidth bottleneck (Memory Wall), whereas computational storage places the compute unit in non-volatile storage (SSD) to target the storage-to-host data movement bottleneck. The two simply operate at different tiers while sharing the philosophy of "computing next to the data," and can work complementarily across the entire memory hierarchy.
An in-memory database is an approach that loads data entirely into DRAM to eliminate access latency but has clear capacity and cost limits, whereas computational storage keeps large data on cheap flash and filters it first-stage in place to reduce the very amount to be raised to the upper tier. Also, whereas past Active Disk and intelligent-storage research remained in dedicated environments, today's computational storage integrates with the host ecosystem on open standards such as NVMe, SNIA, and Wasm, greatly improving immediate applicability and portability.
The relationship with SmartNIC/DPU is also worth noting. If a DPU offloads data movement, security, and virtualization on the network path, computational storage offloads data processing on the storage path. Both share the same vein as "infrastructure offloading" that frees the host CPU from data processing burden, and in data centers DPU, computational storage, and PIM converge toward each dividing a path to focus the host on application logic. Thus computational storage should be understood not as a standalone technology but as one axis composing data-centric infrastructure. The table below summarizes which bottleneck at which tier each data-centric computing technology targets.
| Technology | Compute location | Target bottleneck | Data character |
|---|---|---|---|
| PIM | inside DRAM(volatile memory) | memory bandwidth(Memory Wall) | active working set |
| Computational storage | inside/near SSD(non-volatile) | storage-host data movement | large persistent data |
| In-memory DB | host DRAM | disk access latency | DRAM-loadable scale |
| DPU/SmartNIC | network path | network I/O, virtualization overhead | flowing packets/streams |
As the table shows, the four technologies are not in competition but in a complementary relationship that divides the bottlenecks of different tiers. Therefore, in actual infrastructure design, it is desirable to first diagnose whether the workload's bottleneck is memory bandwidth, storage movement, or the network, and then combine the appropriate offloading technologies.
5. Deep dive — standardization trends and practical adoption strategy
Software and interface standardization is decisive in computational storage moving beyond the lab to an industry standard. This is because no matter how fast the hardware is, it will not be adopted if developers cannot use it easily with existing programming models. SNIA officially approved the Computational Storage Architecture and Programming Model v1.0 in 2022, establishing common terms and a role model such as CSx, CSD, CSP, CSA, and CSF, and then released the Computational Storage API v1.0 for application integration. The NVMe camp is filling the device-control layer through the Computational Programs specification expressing computation as standard commands. As three standards of different layers interlock this way, the once vendor-fragmented ecosystem is converging. The standard stack divides roles as follows.
- Device and programming model (SNIA Architecture & Programming Model): a conceptual standard defining device structure and roles such as CSx, CSD, CSP, CSA, CSE, CSF, and FDM. It provides a vendor-neutral common vocabulary.
- Command interface (NVMe Computational Programs): standardizes the loading, execution, and result return of compute programs as NVMe commands, controlling the device on top of the existing NVMe driver and queue model.
- Programming API (SNIA Computational Storage API): defines the calling convention by which an application discovers, downloads, and executes a CSF and handles the FDM, guaranteeing the portability of upper software.
Only when these three layers all align can "acceleration logic written once run on devices from multiple vendors," and failing that, lock-in to a specific device arises.
For practical adoption, determining workload fit is the starting point. Computational storage gains much in tasks where "the result shrinks dramatically relative to the data read (large reduction ratio)"—that is, scan, filter, aggregation, and compression—and conversely is unsuited to tasks that barely reduce data while repeating complex computation. Also, since the compute resource inside the storage device is lower in performance than the host CPU, designing the division of labor of "what in the device and what in the host" is the key to performance. Recently, Linux Foundation open projects and CSD vendors are lowering integration burden by providing common runtimes and drivers, and attempts to expose computational storage as a resource in Kubernetes environments are also continuing.
Its application value stands out especially in the edge and AI domains. Edge environments are limited in both network bandwidth and power, so performing inference, summarization, and anomaly detection inside the storage device before sending sensor/video data to the center can reduce both the data to be raised upward and the power consumed at the same time. A configuration where an ARM-core CSD runs a lightweight model inside the storage device to finish first-stage classification is representative. In AI training pipelines too, pushing preprocessing—decoding, resizing, normalizing tens to hundreds of terabytes of raw data—down to the storage device can ease the input bottleneck where the GPU idles waiting for data loading. However, to actually reap such effects, all three layers of the standard stack—device model (SNIA), command interface (NVMe), programming API (SNIA CS API)—must align, and this becomes the key checkpoint for vendor selection and architecture design.
From a domestic (Korea) perspective the significance is also great. As Samsung Electronics and SK hynix lead the global memory/storage market, computational storage becomes a strategic technology for shifting beyond mere storage-media supply to high-value solutions. Samsung targeting database/analytics acceleration with its FPGA-combined SmartSSD, and the memory industry including computational storage in its "memory-centric computing" roadmap alongside PIM and CXL, are extensions of such a strategy. In a professional-engineer answer, on this basis, a narrative that positions computational storage not as an individual device technology but as the intersection of data-center architecture reshaping and the advancement of the domestic semiconductor industry carries persuasive force.
6. Considerations and implications (professional-engineer perspective)
Computational storage is not a technology that "pushes all computation down to the storage device," but a selective optimization means that raises overall system efficiency by reducing data movement. Therefore, the adoption decision should be made from a comprehensive perspective that weighs application strategy, trade-offs, standards, security, and operations together, not from a single performance figure.
- Application strategy — selective offloading and division-of-labor design: Computational storage gains much only in memory/IO-intensive sections with a high data reduction rate. One must profile queries/pipelines to assign to the device only the kernels that reduce bus traffic, such as scan, filter, and compression, and design a heterogeneous division of labor where the host CPU/GPU handles complex, repetitive computation. Weighing the reduction ratio together with device compute performance is the practical criterion.
- Trade-off — performance, power, complexity: The compute resource inside a storage device is lower in processing capability than the host, and the thermal/power budget (typically a few to a few tens of watts per drive) is also limited. Enlarging the compute logic may reduce the resources available for media control and endurance, and the programmable approach is flexible but high in development and verification complexity. Setting the boundary of how far to process inside the device is the essential challenge of the design.
- Standard and ecosystem dependency: For hardware performance to translate into real-use performance, SNIA/NVMe standards and compiler/runtime/driver support are essential. If standards are lacking, vendor fragmentation lowers portability and increases lock-in risk, so alignment with open standards (SNIA, NVMe, Wasm) should be made the priority criterion of the adoption decision.
- Security and reliability: Because code sent down by the host is executed inside the device, there is a risk that malicious or faulty code damages the storage device or leaks data. Sandbox isolation such as eBPF/Wasm, code signing and verification, and mechanisms guaranteeing the integrity of computation results are needed, and the key-management policy when decrypting encrypted data inside the device must be designed together.
- Operations and observability: Because computation happens "invisibly" inside the device, tracing the cause of performance degradation or errors is harder than in a centralized form. One must have both a monitoring system that standardly exposes per-CSF throughput, latency, power, and device queue state, and an operational strategy that consistently manages device firmware and CSF versions, to operate it reliably in a real environment.
- Outlook — reshaping toward data-centric infrastructure: As data gravity grows, the flow of "sending compute toward the data" is expected to strengthen. Computational storage will evolve, combined with PIM, CXL, and SmartNIC (DPU), into a heterogeneous acceleration infrastructure centered on minimizing data movement (data-centric computing), and is likely to establish itself as a key means of lowering host CPU dependence in AI data pipelines, large-scale analytics, and edge environments.
References
- SNIA, "Computational Storage Architecture and Programming Model v1.0", https://www.snia.org/sites/default/files/technical-work/computational/release/SNIA-Computational-Storage-Architecture-and-Programming-Model-1.0.pdf
- SNIA, "Computational Storage API v1.0", https://www.snia.org/sites/default/files/technical-work/csapi/release/Computational_Storage_API_v1.0.pdf
- SNIA Blog, "Reaching a Computational Storage Milestone", https://www.snia.org/blog/2022/reaching-computational-storage-milestone-0
- "Past, Present and Future of Computational Storage: A Survey", https://arxiv.org/pdf/2112.09691
In one line: Computational storage is a data-centric architecture that places compute resources inside or near an SSD so that first-stage processing such as filtering, compression, and encryption finishes within the device without moving all data to the host, reducing the data-movement bottleneck and host load; on top of SNIA/NVMe standards, its success hinges on a heterogeneous division-of-labor design that selectively offloads high-reduction intensive operations, and on securing security and the ecosystem.