Edge-First Genomics: Why the Lab of the Future Processes Data Locally

Nicolas Waern WINNIIO AB / Life Atlas ORCID: 0000-0001-7970-2707

Corresponding author: ceo@winniio.io

License: CC-BY-4.0

Submitted: 2026-04-16

Abstract

Genomics is a data-intensive science with a structural compute placement problem. Sequencing instruments generate raw data at rates that exceed most institutional network capacities; cloud-based analysis pipelines introduce latency, data transfer costs, compliance complexity, and dependency on third-party infrastructure that is architecturally misaligned with the operational tempo and sovereignty requirements of clinical genomics laboratories. This paper analyses the case for edge-first compute architecture in genomics — where primary bioinformatics processing runs locally on laboratory hardware, and only structured, reduced-representation outputs are transmitted to cloud or institutional repositories — through a design science research framework augmented by Actor-Network Theory. We distinguish this argument from the parallel case for edge-first epigenomics QC (Waern, 2026b, DOI: 10.5281/zenodo.19602343), which focuses on quality control of methylation data; the present paper is concerned with the placement of primary analysis compute across the full genomics pipeline, from base calling through variant calling to clinical annotation. We trace the actant network of the typical institutional genomics pipeline — sequencing instruments, institutional computing clusters, cloud storage, bioinformaticians, clinical interpretation workflows, regulatory data residency requirements — and identify the translation bottlenecks that produce the manual pipeline delays, data transfer costs, and compliance gaps that characterise the current state. We propose a five-layer edge-first architecture and evaluate it against the SaaS model alternative, arguing that while SaaS pipelines reduce operational complexity for small-throughput laboratories, they are architecturally misaligned with the sovereignty and tempo requirements of clinical-scale genomics. Three falsifiable propositions are stated. We engage the counter-argument that commodity cloud compute is cheaper than local hardware and argue that the relevant cost comparison includes data transfer, compliance overhead, and operational delay — costs that are systematically excluded from cloud vendor pricing comparisons. The paper contributes a compute placement decision framework for genomics laboratories at different throughput scales.

Keywords: edge computing, genomics, bioinformatics, local inference, data sovereignty, pipeline bottleneck, life sciences, digital twin, Actor-Network Theory, design science research, GDPR, compute placement, sequencing throughput

1. Introduction: The Pipeline Bottleneck Nobody Counts

A modern short-read sequencing instrument can generate 2–6 terabytes of raw BCL data per run. The instrument finishes its run in 24–48 hours. The bioinformatician queuing the analysis job on an oversubscribed institutional computing cluster waits another 24–72 hours for the job to start. The data transfer from instrument to cluster takes 4–8 hours on a typical 1 Gbps institutional network. The analysis pipeline runs for 6–12 hours per sample. The variant calling quality review requires another half-day of manual curation. The clinical annotation query against a cloud-hosted database introduces another round-trip latency.

From sequencer run completion to clinically actionable variant report: three to seven business days. In an oncology context where treatment decisions depend on somatic variant status, or a neonatal intensive care context where a diagnosis affects surgical decisions, this latency is not an administrative inconvenience. It is a clinical consequence.

The standard response to this problem in genomics informatics has been to move more of the pipeline to the cloud. Cloud-based bioinformatics platforms offer elastic compute that eliminates queue waiting time, managed pipeline infrastructure that reduces bioinformatician operational overhead, and vendor-maintained databases that are always current. Several commercial bioinformatics platforms have built substantial clinical genomics businesses on this model.

This paper argues that the cloud-first response misidentifies the bottleneck. The primary latency driver in clinical genomics is not queue waiting time on an underprovisioned cluster — it is data movement. Raw genomics data is large, moving it is slow relative to the pace at which sequencers generate it, and moving special-category health data across international boundaries introduces regulatory complexity (GDPR Article 46 for transfers outside the EEA, data residency requirements under national health information legislation) that adds compliance overhead to every cloud transfer.

Edge-first architecture — where the compute runs where the data is generated, rather than moving the data to where the compute is — eliminates the data movement latency, eliminates the cross-border transfer compliance problem, and reduces the pipeline from a multi-day sequential chain to a continuous, instrument-co-located process.

This argument is complementary to but distinct from the edge-first epigenomics QC case made elsewhere (Waern, 2026b). That paper addresses quality control of methylation sequencing data and is focused on the specific data characteristics of epigenomic assays. The present paper addresses compute placement for the full genomics analysis pipeline and is concerned with the structural architecture of the laboratory's information processing system.

2. Theoretical Framework

2.1 ANT and the Genomics Pipeline Network

The genomics laboratory pipeline is a heterogeneous network of actants whose properties have co-evolved over decades of hardware capability improvements, software infrastructure development, institutional procurement decisions, and regulatory requirements. Understanding why the current architecture is the way it is — and what it would take to change it — requires tracing the translations through which each actant was enrolled in its current role.

ANT [1][2] is appropriate here because the compute placement problem is not primarily technical. The institutional computing cluster is an actant whose position in the network is the result of specific historical translations: IT departments enrolled it as the centralised compute resource for all laboratory workloads; bioinformaticians enrolled it as their primary analysis environment; research administrators enrolled it as a cost-allocation mechanism. Replacing it with edge-local compute requires re-enrolling each of these actors — and some, particularly IT departments with strong incentives to maintain centralised infrastructure governance, will resist.

The concept of inscription [3] is central: the institutional cluster inscribes a specific assumption about data flow (data moves to the compute) that is deeply embedded in bioinformatics pipeline tooling, institutional storage architectures, and IT governance policies. Reversing this inscription — making the compute move toward the data, or making the compute co-located with the data generation instrument — requires overcoming not just technical inertia but institutional inertia.

2.2 Design Science Research Frame

Following DSR methodology [4], this paper proposes a five-layer edge-first genomics architecture as a designed artefact. The architecture is evaluated against the SaaS pipeline alternative and the institutional cluster model through scenario analysis. The paper distinguishes between the capabilities of existing component technologies (local GPU compute, containerised pipeline tooling, instrument-integrated base calling) and the capabilities of the proposed integrated architecture.

2.3 Compute Placement as a Design Principle

Following Waern (2025b, DOI: 10.5281/zenodo.17464804), compute placement is treated as a first-class architectural decision — not an operational detail. The principle is: compute should be placed where it reduces the highest-impact latency in the pipeline, subject to the constraints of data sovereignty, regulatory compliance, and cost. This principle produces different answers for different pipeline stages, and the edge-first architecture presented below reflects stage-differentiated placement decisions.

3. As-Is Analysis: The Standard Genomics Pipeline

3.1 Pipeline Stages and Compute Placement

The standard short-read genomics pipeline for clinical applications involves the following stages, each with current compute placement:

Total latency for a single sample (typical): 13–53 hours of processing time, plus queue wait time (2–72 hours) and data transfer time (2–12 hours). For a batch of 24 samples (a full sequencing run), total elapsed time to clinical report: 3–7 days.

3.2 Data Movement as the Hidden Cost

The data transfer problem is systematically undercosted in cloud-versus-local compute comparisons. A sequencing run producing 3 TB of raw BCL data requires approximately 3.3 hours to transfer over a 2 Gbps network connection (under ideal conditions) or 6.7 hours over a typical 1 Gbps institutional connection. Cloud egress pricing for 3 TB of data is not zero — major cloud providers charge egress fees for data transferred out of their regions, and for a laboratory running five sequencing instruments this is a material cost.

More significantly, GDPR Article 9 (special category data — genomic data is explicitly listed) and Article 46 (transfers to third countries) impose compliance obligations on any transfer of genomic data to cloud infrastructure operated outside the EEA, or to any cloud operator that processes the data under a legal framework incompatible with EU data protection requirements. For many academic and NHS laboratories, the compliance overhead of maintaining a cloud genomics pipeline — Data Processing Agreements, Transfer Impact Assessments, cross-border transfer safeguards — adds months to the procurement process and recurring legal review to the operational model.

3.3 Manual Bottlenecks and Queue Saturation

The manual interpretation stage — bioinformatician variant curation and clinical review — is the single largest latency contributor in well-resourced laboratories with adequate compute. It is also the stage that most resists automation for clinical applications: the AI Act's high-risk AI classification for medical decision support (Annex III) requires meaningful human oversight for any AI-assisted clinical variant interpretation.

But the manual interpretation stage is currently underserved by automated upstream processing. Bioinformaticians spend significant time on variant QC tasks — checking coverage metrics, flagging pipeline artefacts, adjudicating borderline quality filter results — that are automatable with current ML tools if the compute architecture supports continuous, instrument-co-located processing rather than batch submission to an oversubscribed cluster.

4. Edge-First Architecture: Proposed To-Be State

4.1 Five-Layer Architecture

The proposed edge-first genomics architecture places compute at the instrument where computationally intensive data transformation reduces data size by 10–100x, and retains only structured, reduced-representation outputs for transmission to institutional repositories or cloud services.

Layer 1 — Instrument-integrated base calling. Base calling (BCL to FASTQ) runs on GPU compute co-located with or integrated into the sequencing instrument. This is already the operational model for several current generation sequencers; it is included here for completeness and because its adoption is uneven across the installed base. Output: FASTQ files (~10x smaller than BCL).

Layer 2 — Local alignment and variant calling. A local GPU compute node (GPU workstation or small GPU server with 64–128 GB RAM and 4–8 TB NVMe storage) runs alignment and variant calling pipelines on FASTQ input, producing aligned BAM/CRAM files and raw variant call files (VCF). This layer handles the computationally intensive but highly automatable stages that currently dominate cluster queue time. Output: VCF files (~1,000x smaller than raw BCL).

Layer 3 — Edge annotation and QC. Variant annotation against locally cached databases (clinically relevant databases synced nightly from authoritative sources) and automated QC metric generation run on the same local node. Output: annotated VCF with QC report (~equivalent size to VCF).

Layer 4 — Structured clinical output generation. An AI-assisted interpretation layer — a classification model trained on curated variant databases, running locally, generating a structured pre-report — flags variants by clinical significance tier and generates a structured draft report for bioinformatician review. All AI-assisted outputs are flagged as requiring human review before clinical action (EU AI Act Article 14 compliance). Output: structured pre-report JSON (~kilobytes per sample).

Layer 5 — Institutional repository sync. Structured outputs (VCF, QC report, pre-report JSON) are synced to institutional repositories or consented cloud services. Raw FASTQ and BAM files are retained locally under the laboratory's data management policy; only the reduced-representation outputs cross the network boundary. This eliminates the GDPR Article 46 cross-border transfer problem for raw genomic data, as only structured clinical outputs — not raw sequence data — leave the local environment.

4.2 Cost and Latency Comparison

The edge-first architecture does not dominate on every metric. It requires capital investment in local GPU compute; it places maintenance responsibility on the laboratory rather than a vendor; and it does not provide the elastic scalability of cloud compute for laboratories that experience highly variable throughput. For laboratories with low or irregular throughput, the SaaS model may be a better fit. The edge-first architecture is proposed as the appropriate model for laboratories with throughput above approximately two sequencing runs per week and with strong data sovereignty requirements.

5. The ANT Reading: Enrolling Actants in the Edge-First Network

The edge-first architecture requires specific actant translations that the cloud-first model does not:

IT departments. The institutional IT department must accept that a laboratory GPU node is a legitimate data processing infrastructure — not a shadow IT workaround — and must provide network integration, backup, and security coverage for it. This translation requires the laboratory to engage IT governance processes that cloud procurement typically bypasses (since SaaS does not require on-premise hardware).

Bioinformaticians. Local pipeline infrastructure requires bioinformaticians to take operational ownership of the pipeline tooling: version management, containerisation, database synchronisation. This is additional responsibility that SaaS pipelines abstract away. The translation requires demonstrating that edge-first infrastructure reduces the interruptions caused by cluster queue delays and cloud service outages, and that the operational overhead is lower than the productivity cost of waiting.

Regulatory and compliance functions. The data protection office must be enrolled in the argument that edge-first architecture reduces compliance burden (by eliminating cross-border transfers) rather than increasing it (by introducing a new category of locally processed special-category data). This translation is straightforward for laboratories with existing on-site compute infrastructure but requires active work for laboratories currently operating under a cloud-first data governance framework.

Instrument vendors. Several major sequencing instrument vendors have proprietary analysis platforms that prefer or require cloud connectivity for data processing. Enrolling instrument vendors in the edge-first network may require negotiation of local pipeline support options — or selection of instruments whose analysis platforms are compatible with local deployment.

6. Counter-Argument: Cloud Compute Cost and Scalability

The primary counter-argument is economic: commodity cloud GPU compute is available on a per-hour basis at prices that are difficult to match with owned hardware, particularly for small laboratories that cannot fully utilise a local GPU node. The scalability argument reinforces this: when a laboratory runs a large project requiring 100 sample analyses in a week, cloud compute scales elastically; a local node with fixed capacity creates a processing queue.

This argument is correct for low-throughput and highly variable throughput laboratories. The edge-first model is not proposed as a universal replacement for cloud or institutional cluster models. It is proposed as the appropriate architecture for laboratories with throughput above the local compute utilisation threshold — approximately two full sequencing runs per week for a single GPU workstation — and with data sovereignty requirements that make cross-border cloud transfer compliance costly.

To make the crossover threshold concrete: AWS HealthOmics list pricing for a standard whole-genome sequencing alignment run (approximately 3 TB raw input, paired-end 150 bp reads, alignment to GRCh38) is approximately USD 8–12 per sample at current published rates, with additional storage and egress charges bringing a complete alignment-to-VCF run to approximately USD 15–25 per sample at medium depth (30x). A GPU workstation with adequate specification for genomics workloads (e.g., 8-core CPU, 128 GB RAM, NVIDIA RTX 4090 or equivalent, 8 TB NVMe, 3-year lifecycle) has a capital cost of approximately USD 8,000–12,000 and an annual electricity and maintenance cost of approximately USD 800–1,200. Amortised over a 3-year lifecycle with a 50% utilisation assumption, this yields an effective local compute cost of approximately USD 1.50–3.00 per sample run for a laboratory processing 100+ samples per month. At approximately USD 15–25 per cloud run versus USD 1.50–3.00 per amortised local run, the crossover point — where cumulative local infrastructure cost equals cumulative cloud spend — is reached at approximately 100–140 samples total (roughly 2–3 months at two full runs per week). Beyond this threshold, every additional run reduces the effective cost differential in the edge-first model's favour. This calculation excludes compliance overhead and egress fees, which further favour local processing for EEA laboratories handling GDPR special-category genomic data.

The cost comparison must include: cloud egress fees for raw genomic data (typically 0.05–0.09 USD per GB from major cloud providers, which is material for a laboratory moving terabytes per month); compliance overhead (legal review of Data Processing Agreements and Transfer Impact Assessments); and the opportunity cost of pipeline delays (which are not a line item in any cloud vendor pricing comparison).

When these costs are included, the edge-first model is frequently cost-competitive with SaaS at medium-to-high throughput scales.

7. Falsifiable Propositions

1. The latency proposition: Genomics laboratories that implement edge-first architecture (local alignment, variant calling, and annotation) will achieve sample-to-clinical-report turnaround times at least 40% shorter than equivalent laboratories using institutional cluster or SaaS cloud pipelines, at throughput above two sequencing runs per week. This proposition can be falsified by a time-motion study of matched laboratories showing no significant turnaround time difference after controlling for throughput.

2. The compliance cost proposition: The total compliance cost (legal review, Data Processing Agreement maintenance, Transfer Impact Assessments) of maintaining a cross-border cloud genomics pipeline exceeds the capital and operational cost of equivalent local compute infrastructure for EEA-based clinical genomics laboratories processing more than 500 samples per year. This proposition can be falsified by a cost accounting study showing cloud compliance costs below local infrastructure costs at this throughput level.

3. The data sovereignty proposition: Clinical genomics laboratories operating under national health information legislation with data residency requirements cannot achieve GDPR Article 46 compliance for raw sequence data transfers to US-headquartered cloud providers under current (post-Schrems II) legal frameworks without implementing supplementary measures that eliminate the operational efficiency advantages of cloud processing. This proposition can be falsified by a legal analysis identifying EU-headquartered cloud infrastructure options that provide equivalent compute capacity without triggering Article 46 obligations.

8. Limitations and Future Research

The cost comparison presented in Section 4.2 is based on illustrative figures derived from published cloud pricing schedules and typical hardware costs; it is not based on primary data from specific laboratories. The throughput threshold above which edge-first architecture is cost-competitive with SaaS varies with specific instrument types, pipeline complexity, and national regulatory context.

The AI-assisted interpretation layer (Layer 4) is described at a functional level; its clinical validation requirements under the EU AI Act's high-risk AI framework are not fully addressed. For clinical deployment, this layer requires conformity assessment, clinical validation studies, and ongoing performance monitoring.

Future research should: (1) conduct a cost accounting study of matched clinical genomics laboratories comparing all-in costs of cloud, institutional cluster, and edge-first architectures; (2) develop and validate containerised pipeline configurations optimised for the specific compute architecture of current laboratory-scale GPU hardware; (3) assess the AI Act compliance pathway for local edge AI interpretation tools in clinical genomics contexts.

9. Conclusion

The lab of the future does not send its data to the cloud for processing. It processes its data locally, generates structured outputs, and transmits the structured outputs to institutional repositories and clinical systems. This is not a nostalgia for local computing — it is a recognition that the genomics pipeline's data characteristics (volume, velocity, sovereignty requirements, latency sensitivity) are mismatched with the cloud-first model that has become the default assumption in bioinformatics infrastructure discussions.

Edge-first genomics is not a fringe position. It is the logical consequence of taking seriously the constraints that clinical genomics laboratories actually operate under: GDPR special-category data obligations, data residency requirements, turnaround time expectations in clinical contexts, and the data transfer physics of multi-terabyte sequencing runs on typical institutional networks.

The architecture is available now. The tooling — containerised pipeline frameworks, GPU-optimised alignment and variant calling software, local annotation database management systems — is mature. What is needed is the translation of institutional actants (IT departments, procurement frameworks, data governance policies) into acceptance of edge-first compute as a legitimate, well-governed alternative to centralised and cloud-based models.

That translation is not primarily a technical argument. It is an economic and regulatory argument. This paper has aimed to make it.

References

[1] Callon M. Some elements of a sociology of translation: domestication of the scallops and the fishermen of St Brieuc Bay. In: Law J (ed.) Power, Action and Belief. Routledge, 1986: 196–223.

[2] Latour B. Science in Action. Harvard University Press, 1987.

[3] Akrich M. The de-scription of technical objects. In: Bijker W, Law J (eds.) Shaping Technology/Building Society. MIT Press, 1992: 205–224.

[4] Hevner AR, March ST, Park J, Ram S. Design science in information systems research. MIS Quarterly 2004;28(1):75–105.

[5] Langmead B, Salzberg SL. Fast gapped-read alignment with Bowtie 2. Nature Methods 2012;9(4):357–359.

[6] Van der Auwera GA, O'Connor BD. Genomics in the Cloud: Using Docker, GATK, and WDL in Terra. O'Reilly Media, 2020.

[7] European Data Protection Board. Guidelines 05/2021 on the Interplay between the Application of Article 3 and the Provisions on International Transfers as per Chapter V of the GDPR. EDPB, 2021.

[8] Waern N. Edge-First Epigenomics QC: Local-First Quality Control for Methylation Sequencing Data. Zenodo, 2026. DOI: 10.5281/zenodo.19602343. [Waern 2026b]

[9] Waern N. Edge-Native Biological Digital Twins: Architecture Principles for Local-First Personal Health Intelligence. Zenodo, 2025. DOI: 10.5281/zenodo.17464804.

[10] Waern N. SMILE: A Methodology for Impact-First Digital Twin Deployment in Complex Sociotechnical Systems. Zenodo, 2026. DOI: 10.5281/zenodo.19587944.