Planning spatial biology data management badly is the most common way a well-specified program runs into trouble, usually within the first year. The instrument is funded, the assays work, and then storage fills, analysts cannot reach the data, and nobody owns the problem. Most of that is avoidable, and it starts with getting the volume question right, because the number most often quoted is the wrong one.
Key Takeaways
|
How Big Is Spatial Data, Really?
The honest answer is that it depends entirely on which data you mean, and conflating the two is why storage estimates for spatial programs are so often wrong by orders of magnitude.
Take an imaging-based platform as the clearest example. 10x Genomics’ own guidance on archiving Xenium data states that internal image sensor data amounts to roughly tens of terabytes per sample, that it cannot be reanalyzed after processing by the onboard software, and that it is not practically useful to store. In other words, the terabyte-scale figure that circulates in conversation describes data the vendor explicitly recommends discarding.
What you keep is much smaller. The Allen Institute for Immunology’s documentation for ingesting Xenium data puts the output directory for a single slide with the full imageable area selected at 7 to 60 GB, depending on tissue and panel, with a run of four slides therefore falling somewhere between 28 and 240 GB. That is roughly three orders of magnitude below the raw sensor figure.
What | Scale | Keep It? |
Internal image sensor data, imaging-based platform | Tens of terabytes per sample | No. Vendor states it cannot be reanalyzed after onboard processing and is not practically useful to store |
Decoded transcripts plus morphology images | 7 to 60 GB per slide | Yes. This is the recommended archival set, and what repositories and funders expect |
Full run output, four slides | Approx. 28 to 240 GB | Yes, as above, scaled by slides per run |
Sequencing-based expression matrix | Hundreds of thousands of features per section | Yes. Compact on disk but demanding in memory during analysis |
Derived and intermediate analysis files | Highly variable, often exceeding the raw archive | Selectively. Regenerable from raw plus recorded parameters |
Table 1. Spatial data by category. Figures are drawn from vendor archiving guidance and published pipeline documentation, and vary with configuration, tissue, and panel. Establish your own numbers from a real run before sizing storage.
Sequencing-based platforms behave differently. Their footprint on disk is modest, but the matrices are large in a way that matters for memory rather than storage. Benchmarking on Visium HD samples has worked with sections yielding over 516,000 spatial features at more than 1,600 genes, and the technical comparison across six cancer types notes that a high-definition capture area holds roughly 11 million bins at native 2 micron resolution, which is why most analyses aggregate to 8 or 16 micron bins and reduce that to hundreds of thousands. Storage is not the constraint there. Compute is.
What You Keep Is Not What the Instrument Produces
The practical consequence of the above is that your retention policy is a bigger determinant of storage cost than your platform choice. Three decisions do most of the work, and all three should be made before the first run rather than after storage fills.
- What constitutes your raw archive. Follow vendor guidance on which outputs are genuinely primary. For imaging platforms, this typically means decoded transcripts and morphology images in open formats rather than sensor data. Getting this wrong in the conservative direction is expensive; getting it wrong in the other direction is irreversible.
- How long you keep it. Retention is usually driven by funder requirements and reanalysis expectations rather than project length, and reanalysis expectations tend to run for years. Multiply your annual accumulation by the retention period, not by the project duration.
- What you regenerate rather than store. Intermediate and derived files often exceed the raw archive in aggregate and can usually be recreated from raw data plus recorded parameters. That only works if the parameters were recorded, which makes it a workflow discipline question as much as a storage one.
One further point that catches people out: the archive grows monotonically while the instrument keeps running. A program producing a modest amount per run still accumulates steadily, and unlike consumables, storage from three years ago is still costing you money today. That is why the storage line in a cost model behaves differently from every other line, as set out in How Much Does Spatial Biology Cost? Budgeting for Instruments, Consumables, and Data. Detailed sizing methods are in [LINK: How Big Is Spatial Biology Data? Planning Storage and Compute Capacity].
Storage Architecture Options
Choose by access pattern rather than by technology. Spatial data has three distinct lives: it is written once at high speed off the instrument, read repeatedly and randomly during active analysis, then read rarely but needs to remain retrievable for years. Trying to serve all three from one tier is how labs end up paying premium rates to store data nobody has opened in eighteen months.
Tier | Typical Implementation | Suits | Watch For |
Instrument-adjacent | Local disk on the analysis computer | Transient staging only, until transfer completes | Becoming a de facto archive because nobody moved the data |
Active analysis | On-premise high-performance storage or fast cloud storage | Data under current analysis, needing random access | Cost if it holds everything rather than current work |
Reference | Network-attached storage or standard object storage | Completed projects still consulted | Access speed, if analysts work directly against it |
Archive | Cold object storage or tape | Long-term retention for funders and reanalysis | Retrieval time and egress or recall charges |
Repository deposit | Public repositories in accepted formats | Published datasets, often mandated | Format conversion effort if not planned from the start |
Table 2. Storage tiers by access pattern. Most labs need at least three of these. The costly mistake is holding everything in the second tier by default.
Lab Quality Management Certificate
The Lab Quality Management certificate is more than training—it’s a professional advantage.
Gain critical skills and IACET-approved CEUs that make a measurable difference.
The cloud versus on-premise question is genuinely open and depends on factors specific to your institution: whether capital or operating budget is easier to secure, whether your institution already has storage infrastructure and at what internal rate, how much data you will move in and out, and whether your data governance permits external hosting. Egress charges deserve particular scrutiny, because a model that looks cheap while data accumulates can become expensive the moment analysts start moving it repeatedly. Get your institutional per-terabyte rate before modeling anything, and compare it against quoted cloud pricing on the same retention period. The trade-offs in depth are in [LINK: Building Compute Infrastructure for Spatial Analysis: On-Prem vs. Cloud].
What Compute Do You Actually Need?
Compute requirements for spatial work are driven by memory and by task, not by data size on disk, which is the opposite of the intuition storage planning gives you. A modest archive can require substantial memory to analyze.
Task | Dominant Constraint | Practical Implication |
Loading and filtering large expression matrices | Memory | Sections with hundreds of thousands of features can exceed a workstation |
Cell segmentation on image data | Compute, often accelerated hardware | Frequently the longest single analysis step |
Clustering and cell typing | Memory and CPU | Scales with cell count, which scales with imaged area |
Spatial statistics and neighborhood analysis | CPU, sometimes memory | Can be slow enough to make iteration painful on undersized hardware |
Visualization and exploration | Random read speed and memory | Where analysts most feel undersized infrastructure day to day |
Reanalysis of archived data | Retrieval time, then all of the above | Archive tier choice determines whether this takes hours or days |
Table 3. Analysis tasks and what limits each. Requirements depend heavily on platform, imaged area, and software choice, so validate against a real dataset from your own configuration.
Interested in lab leadership?
Two practical recommendations. First, size compute against a real dataset from your intended configuration rather than a vendor guideline, ideally one obtained during platform evaluation. Second, put the analysis environment where the data already is. Making analysts download large datasets to local machines wastes time, multiplies copies, and creates a governance problem, and it is one of the clearest signals that infrastructure was planned around the instrument rather than the workflow.
Whether you need institutional high-performance computing depends on scale and software. Many labs run adequately on a well-specified server with generous memory, and reach for shared computing only for segmentation or large cohort analyses. The honest test is whether your analyst is waiting on hardware, and that question is answerable only once someone is actually doing the work.
Data Management and Governance
Governance sounds like an administrative concern and behaves like a technical one, because decisions made casually at the start constrain everything afterward. Four areas need explicit answers.
- File formats and interoperability. Format choice determines which tools you can use for the life of the data. The OME next-generation file format exists because traditional monolithic image formats stop working at this scale, and vendors increasingly output open formats such as Zarr, Parquet, and OME-TIFF. Prefer open formats for anything you intend to keep.
- Metadata and findability. A dataset nobody can locate or interpret in three years has been stored rather than preserved. Capture sample provenance, run configuration, and processing parameters alongside the data, not in someone’s notebook.
- Access control and consent scope. For human tissue, who may access the data and where it may be hosted are consent and ethics questions, not IT preferences. Confirm before choosing a hosting model rather than afterward.
- Retention and disposal. Write down what is deleted when, and who authorizes it. Without a disposal policy, retention becomes indefinite by default, which is the most expensive outcome available.
Vendor practice is moving in a helpful direction here. 10x, for instance, frames its archiving guidance explicitly around findability, accessibility, interoperability, and reusability, and recommends open formats for the archival set. Aligning your own practice with that costs little at the start and is difficult to retrofit. The FAIR principles applied to spatial data are covered in [LINK: Data Management and FAIR Principles for Spatial Datasets], and format questions in [LINK: Image Data Formats and Interoperability in Spatial Biology].
Who Owns the Data Problem?
In most labs, nobody does, and that is the actual finding of this section. Storage is assumed to be IT’s concern, analysis is assumed to be the analyst’s, and the space between them, which is where transfer, formats, metadata, retention, and cost decisions live, is unowned until something breaks.
Name an owner for four responsibilities, even if the same person holds all four.
- Capacity planning. Forecasting accumulation, monitoring headroom, and requesting expansion before it is urgent.
- Transfer and integrity. Confirming data reaches managed storage complete, and that it left the instrument.
- Standards and metadata. Deciding formats, ensuring parameters are captured, and keeping practice consistent between runs.
- Budget. Owning the recurring storage and compute line and defending it annually, which is the responsibility most often orphaned.
The analyst question sits alongside this and is distinct from it. Infrastructure ownership is not the same as analytical capability, and a lab can have excellent storage and still be unable to interpret its own data. Staffing that gap is covered in [LINK: Who Analyzes the Data? Staffing Bioinformatics for Spatial Biology], and the readiness view of whether these capabilities exist at all is in Is Your Lab Ready for Spatial Biology? A Readiness Assessment.
One closing observation. Because data volume and analysis burden vary considerably between platforms, infrastructure planning belongs in the procurement decision rather than after it. The platform differences that drive it are set out in Spatial Transcriptomics Platforms Compared: Visium, Xenium, CosMx, MERSCOPE, and GeoMx, the workflow that feeds data into this pipeline is in Running Spatial Biology in the Lab: Workflow, Throughput, and Sample Management, and the operational picture across the whole program is in Spatial Biology in the Lab: A Manager's Guide to Evaluating, Implementing, and Scaling Spatial Technologies.
This article was produced under Lab Manager's AI Editorial Guidelines.
