Your ingest pipeline shouldn't need a translation layer.
TrueNAS ingests 10+ GB/s of raw imaging and neural data natively over NFS — no POSIX-to-S3 translation tax, no forced move to all-flash to fix a metadata problem. Scale to petabytes on hybrid storage economics.
Hybrid storage pairs high-capacity disk for bulk data with NVMe flash for metadata and caching, so you get disk economics with flash-speed lookups where it matters.
The OME-Zarr tax: why a "cloud-native" format slows down local ingest
OME-Zarr is the imaging format of choice for microscopy and neural data pipelines — a library you build into your own workflow, not an off-the-shelf tool. It's genuinely good at what it's designed for: bundling imaging data and metadata for distribution. The problem shows up when teams assume its S3 support means native S3, and point it at local storage anyway.
OME-Zarr's "S3" isn't native S3
The library's S3 interface runs on S3FS, which emulates a local file system on top of object storage. That's a reasonable design for pushing data over a WAN, where the bottleneck is the network pipe regardless. It's the wrong tool for local ingest.
Three translation hops before data ever reaches disk
Used locally, that S3FS layer takes a POSIX call, emulates it as an S3 object write, and — once it lands on a system like TrueNAS — that gets emulated back down to POSIX again before ZFS ever touches it. POSIX → S3 → POSIX, then finally the filesystem.
Each hop is a performance tax you didn't need to pay
None of those translations exist because your workload needs them — they exist because the library defaults to a cloud-shaped path. If your pipeline runs on Linux clients talking to local or on-prem storage, that tax is pure overhead.
Point the library at an NFS share instead. That cuts two of the three translation hops — one POSIX call, straight to the filesystem, straight to disk. Same library, same workflow, no code rewrite. Just the native path instead of the cloud-shaped one.
OpenZFS caching + native NFS — not more flash.
You don't need an all-flash array to get flash-like metadata performance. Routing ingest through native NFS — instead of through OME-Zarr's default S3FS path — removes two of the three translation hops before data ever reaches ZFS. Underneath, the OpenZFS caching engine and a dedicated NVMe metadata tier absorb the directory lookup load, so the platform handles millions of small files without an array-wide flash upgrade.
This runs on the same platform that handles your file, block, and S3-compatible object workloads — one operational model, not a separate appliance for imaging.
Engineered for the modern data lab
OpenZFS block replication, not rsync
Syncing millions of files with rsync means tree-walking every directory — slow, and it gets slower as file count grows. TrueNAS replicates at the block level, moving petabytes of sharded data without the tree-walk, and without rewriting your pipeline for multi-node scale.
Hybrid economics
Pair high-capacity HDDs for bulk payload storage with targeted NVMe for metadata and caching. You get most of the performance of all-flash — at a fraction of the media cost.
Local ingest, then Cloud Sync — not cloud-first
Ingest locally over native NFS at full speed, then use TrueNAS Cloud Sync to push the data over S3 to your cloud provider for further transformation. You get the performance of a local-first workflow and still land the data in the cloud pipeline you already planned for — in the right order, not the format's default order.
Predictable commercial terms
All-inclusive licensing, no capacity traps, and 6–8 year deployment lifecycles instead of forced refresh cycles — so budget scales with the lab, not with vendor timing.
Test it before you buy
Download Community Edition and validate ingest performance on your own datasets before procurement.
Engineers who research your format, not just your ticket
When a customer showed up running OME-Zarr, TrueNAS engineers read the library's own documentation, found the S3FS emulation issue, and rewrote the customer's ingest path before it became a production bottleneck. Most storage vendors won't go that deep on a workflow they don't already have a playbook for — you get handed a generic answer instead of an examined one. That's the difference between a vendor and an engineering partner: the research gets done before you pay the performance tax, not after.
Direct engineer access, every proposalPetabyte scale, proven results.
Common questions about OME-Zarr and hybrid storage for AI & imaging
What is OME-Zarr, and why does it matter for storage architecture?
OME-Zarr is an imaging format and library used mainly in microscopy and neural-data pipelines to bundle image data and metadata for storage and distribution. It's a library you build into your own ingest workflow, not a turnkey product — and its default configuration assumes you're pushing data to cloud object storage, not ingesting it locally at high speed.
Does OME-Zarr's S3 support mean it's using native S3?
No. OME-Zarr's S3 interface runs on S3FS, which emulates a local file system on top of object storage. That's a reasonable design for pushing data over a WAN, where the network is the bottleneck regardless. Used for local, high-speed ingest, it adds translation overhead you don't need: a POSIX call gets emulated as an S3 write, then emulated back to POSIX again once it reaches the storage system — before the filesystem ever sees it.
What is hybrid storage?
Hybrid storage combines high-capacity spinning disk for bulk data with NVMe flash for metadata and caching. You get the cost-per-terabyte of disk with the responsiveness of flash for the operations that actually need it — directory lookups, small-file access, metadata-heavy workloads.
Do I need all-flash for AI and imaging workloads?
Not necessarily. If the bottleneck is metadata and small-file overhead — common with sharded imaging datasets and AI ingest pipelines — a hybrid architecture with a targeted NVMe metadata tier can match much of the performance of all-flash at a lower media cost.
Ready to architect your next-gen data lab?
Talk to a TrueNAS engineer, not a rep reading from a script. We'll size your ingest rates, file sizes, and protocol needs — including niche formats like OME-Zarr — and design a system around them, with a design review before you sign anything.
Book an Architectural ReviewNo commitment. No sales pressure. Just numbers.