# Terra vs DNAnexus vs Galaxy: Key Differences Terra is a free, cloud-native research platform built around WDL workflows and Google Cloud infrastructure, DNAnexus is a commercial platform built for regulated clinical and population-scale genomics across AWS, Azure, and Google Cloud, and Galaxy is an open-source, point-and-click analysis framework that anyone can run on a public server, their own lab server, or a cloud provider. The rule of thumb is simple: use Terra when you want GATK best-practice workflows and shared controlled-access datasets with minimal setup, use DNAnexus when compliance, vendor support, or very large clinical and biobank-scale operations drive the decision, and use Galaxy when you want a free, transparent, scriptable-by-clicking environment that you can also host yourself. This article explains each platform on its own terms, compares them on the criteria that decide real choices, walks through worked scenarios, and lists the mistakes that trip up teams moving into cloud bioinformatics for the first time. ## The Short Answer: Which Platform Should You Pick ![Decision path asking about compliance needs, NIH datasets and budget, leading to DNAnexus, Terra or Galaxy.](/article-images/illustrations/terra-vs-dnanexus-vs-galaxy-platform-triage.webp) If you are deciding between Terra or DNAnexus, the deciding factor is usually governance and support rather than raw capability. Both can run production-grade genomics pipelines at scale. Terra gives you a free platform where you pay only the underlying cloud costs, and it comes pre-wired to major NIH-funded datasets. DNAnexus gives you a commercial product with a support contract, a compliance framework, and a track record in clinical and biobank deployments. Galaxy sits outside that comparison in a useful way: it is software you can run anywhere, including on a laptop-sized single-machine install, a university HPC cluster, or a cloud account you control. A quick decision guide: - **Choose Terra** when your analysis centers on GATK, WDL workflows, NIH controlled-access data such as AnVIL or BioData Catalyst workspaces, or notebook-based collaborative analysis on Google Cloud. - **Choose DNAnexus** when you need a supported commercial platform, multi-cloud deployment, clinical-grade compliance features, or a managed environment for a sequencing core or biobank analysis program. - **Choose Galaxy** when you want open-source tooling, a graphical interface for reproducible analysis, training-friendly environments, or the freedom to self-host on your own hardware or on any cloud, including AWS. ## Why Cloud Bioinformatics Exists The shift from desktop tools to web-based platforms is one of the defining changes in [computational biology](/knowledge/bioinformatics/vaccinomics-and-the-future-of-personalized-vaccines). For most of the history of molecular systematics and genomics, researchers managed data in single-user, file-based desktop software that was fundamentally unsuitable for real-time, team-based collaborative work [1]. As sequencing costs fell and datasets grew, that model broke down. A single fastq file from a modern instrument can be tens of gigabytes, and a whole-genome project can generate terabytes. No desktop machine stores, processes, and shares that data efficiently. Cloud bioinformatics solves this by moving three things off the local machine: the data, the compute, and the analysis environment. When data and compute live in the same place, you avoid copying terabytes across the internet, and every collaborator works against the same copy of the data with the same tool versions. This is the software-as-a-service (SaaS) model, in which a web application and database are delivered over the internet rather than installed locally. The approach is well established in biology. MorphoBank, a web application and database for building phenomic matrices, has operated on SaaS methodology compatible with cloud computing since its tenth year of service and has been fully available to the scientific community at large since inception [1]. Its core insight applies directly to genomics platforms: when the data, the analysis record, and the collaboration layer live in one shared web environment, teams can do work that desktop tools cannot support. Terra, DNAnexus, and Galaxy are three general-purpose implementations of this idea for genomics. They differ in who builds them, who pays, how they handle compliance, and how much freedom you have to run them yourself. ## Side-by-Side Comparison The table below is the core of the difference between Terra, DNAnexus, and Galaxy. Each row is expanded in the sections that follow. | Criterion | Terra | DNAnexus | Galaxy | |--|--|--|--| | Developer and operator | Broad Institute, Verily, and Microsoft partnership | DNAnexus (commercial company) | Galaxy Project, an open-source community | | Platform type | Free cloud-native platform, you pay underlying cloud costs | Commercial subscription and usage platform | Free open-source software, public servers free, self-hosting costs your own | | Primary cloud infrastructure | Google Cloud, with expansion to AWS through AnVIL | AWS, Microsoft Azure, and Google Cloud | Any infrastructure, including public servers, HPC clusters, and AWS or other clouds | | Workflow language | WDL, executed by the Cromwell engine | DNAnexus applets and workflows, with support for common workflow standards | Native Galaxy workflows, with Common Workflow Language support | | Interface | Web UI, plus Jupyter and RStudio notebooks | Web UI, plus the dx command-line interface | Web UI, plus interactive tools such as Jupyter and RStudio | | Typical audience | Academic genomics researchers, GATK users, NIH data commons users | Clinical labs, sequencing cores, biotech, population-scale biobanks | Students, core facility users, labs wanting transparent open-source analysis | | Data governance | Workspace-level sharing, integration with NIH controlled-access datasets | Enterprise-grade compliance features for regulated environments | Depends on the server, self-hosting gives you full control | | Cost model | Platform free, cloud usage billed to your billing project | Commercial licensing plus cloud usage | Free on public servers, self-hosting costs your hardware or cloud bill | | Learning curve | Moderate, WDL knowledge helps | Moderate, vendor onboarding and support available | Lowest for point-and-click work, grows with administration | | Signature strength | GATK best practices and shared NIH datasets | Regulated clinical and biobank-scale deployments | Openness, training ecosystem, and self-hosting freedom | ## Terra on Its Own Terms ### What Terra Is Terra is a cloud-native platform for biomedical research developed through a partnership between the Broad Institute, Verily, and Microsoft. It grew out of the Broad's FireCloud platform and has become the analysis layer for several large NIH-funded data resources, including the NHGRI AnVIL ecosystem and BioData Catalyst. The platform itself is free to use. You pay for the underlying Google Cloud compute and storage through a Terra billing project, which is a container that links your Terra usage to a cloud billing account. The design philosophy is that analysis should happen where the data lives. Large controlled-access datasets are hosted in the cloud, and instead of downloading them, you bring your analysis to the data inside a workspace. A workspace is a self-contained project that bundles data references, workflows, notebooks, and access controls. Sharing a workspace with a collaborator shares the entire analysis context, not just a folder of files. ### Workflows and Data in Terra Terra's workflow engine is Cromwell, an open-source workflow manager developed at the Broad Institute that executes workflows written in WDL (Workflow Description Language). WDL is a human-readable language for describing tasks and their dependencies. A simple WDL task might declare that it takes a FASTQ file and a reference genome, runs an aligner inside a Docker container, and outputs a BAM file. Because each task runs in a specified container, the software versions are pinned and reproducible. The most widely used WDL workflows on Terra are the GATK best-practice pipelines for germline and somatic variant calling. The Broad Institute maintains these pipelines and publishes them for use on Terra, which means a researcher can run the same pipeline the Broad's own production teams use, without writing a line of WDL themselves. Workflows can be discovered through Dockstore, a public registry for sharing workflows across platforms. Terra's data model is built around FHIR (Fast Healthcare Interoperability Resources), a healthcare data standard, which lets the platform represent cohort-level metadata, sample relationships, and phenotypic information in a structured way. For interactive analysis, Terra supports Jupyter notebooks and RStudio sessions that run on cloud compute attached to the workspace, so a notebook can query a cohort of hundreds of thousands of genomic records without downloading them. ### When to Use Terra The clearest signals for when to use Terra are these. First, your analysis is GATK-based or otherwise covered by published WDL pipelines, and you want to run them without building infrastructure. Second, you need access to datasets hosted in NIH-funded resources such as AnVIL or BioData Catalyst, which use Terra as their analysis layer. Third, your team works on Google Cloud and wants notebook-based collaboration against large datasets. Fourth, you want the platform itself to be free and are comfortable managing a Google Cloud billing account. ## DNAnexus on Its Own Terms ### What DNAnexus Is DNAnexus is a commercial cloud platform built specifically for genomics and biomedical data. Unlike Terra and Galaxy, it is a product sold by a company, and that shapes everything about it. Customers buy subscriptions and pay for cloud usage, and in return they get vendor support, professional onboarding, and a platform designed to meet the operational demands of regulated and industrial environments. DNAnexus runs on multiple cloud providers, including AWS, Microsoft Azure, and Google Cloud, which matters for organizations that have already committed to a particular cloud or that operate in regions with data residency requirements. In the context of AWS genomics, DNAnexus is one of the major third-party platforms that run on AWS infrastructure, alongside AWS's own [genomics services](/blog/guides/genomics-services) such as Amazon Omics. The multi-cloud posture is a genuine differentiator when a procurement office or an IT department dictates the cloud. ### Workflows and Data in DNAnexus The platform's analysis model is built around apps and applets, which are encapsulated analysis tools with defined inputs, outputs, and execution environments. A workflow chains applets together. Developers can package their own tools, and DNAnexus provides an SDK and a command-line interface, the dx toolkit, with commands such as `dx upload` to move data into a project and `dx run` to launch an analysis. Projects are the organizational unit, and granular permissions control who can view, upload, or execute within each project. DNAnexus has become the platform of choice for several very large population-scale deployments. The most prominent example is the UK Biobank Research Analysis Platform, which puts the UK Biobank's half-million-partner dataset, with its full genomic and phenotypic data, into a DNAnexus-built environment where approved researchers can analyze it in the cloud rather than downloading it. This pattern, bringing analysis to the data at population scale, is exactly the kind of workload the platform was designed for. For clinical work, the platform is built to support regulated environments. Clinical laboratories in the United States operate under frameworks such as HIPAA for patient data privacy and accreditation requirements for testing laboratories, and DNAnexus provides the compliance features, audit trails, and access controls that such environments require. A clinical lab running [exome sequencing](/blog/guides/exome-sequencing) as a diagnostic service needs more than a workflow engine. It needs documented software versions, controlled change management, and an audit trail, and this is where a commercial platform earns its cost. ### When DNAnexus Fits DNAnexus is the right answer when the question is organizational rather than scientific. If your lab is a clinical sequencing operation, a biotech company running regulated analyses, a sequencing core serving many internal customers, or a consortium that needs a vendor to hold the platform together, DNAnexus is built for you. If you are a small academic lab with no compliance burden and no support budget, the commercial model is probably more than you need. ## Galaxy on Its Own Terms ### What Galaxy Is Galaxy is an open-source platform for data-intensive biomedical research, first released in 2005 by a team at Penn State University. It is maintained by the Galaxy Project, a distributed community of developers and system administrators, and it is the oldest of the three platforms discussed here. The defining feature is the graphical interface: every analysis step, from quality trimming to variant calling, is performed through a web form, and every step is recorded in a history that can be shared, rerun, and exported as a workflow. Galaxy is not a single hosted service. It is software. Three things exist under the same name: public servers that anyone can use for free, such as usegalaxy.org in the United States and usegalaxy.eu in Europe, self-hosted instances that labs and institutions run on their own hardware or cloud accounts, and the open-source codebase itself. This is the fundamental structural difference from Terra and DNAnexus. With Galaxy, you can own the whole stack. ### Workflows and Tools in Galaxy Galaxy's tool collection is enormous and community-maintained. Tools are distributed through the Galaxy Tool Shed, a public repository where developers publish wrappers that make command-line tools usable through the Galaxy interface. The collection covers the full breadth of genomics, including RNA-seq, variant calling, proteomics, metagenomics, and image analysis, and it extends into fields like phylogenetics and phenomics, where web-based platforms have historically been slower to develop than in genomics [1]. Workflows are built by clicking tools together in the editor, and a finished workflow can be exported, shared, and rerun on new data. Galaxy also supports the Common Workflow Language (CWL), an open standard for describing workflows portably across platforms, which helps when a team needs to move between systems. For interactive analysis, modern Galaxy instances include interactive tools such as Jupyter notebooks and RStudio that run inside the Galaxy environment. Execution is flexible. A Galaxy instance can run jobs on the server it is hosted on, submit jobs to an HPC cluster through standard schedulers such as SLURM, or distribute work to remote machines through Pulsar, Galaxy's own distributed execution system. This is why Galaxy is common in universities with existing HPC investment: the platform sits on top of the cluster the institution already owns. ### When Galaxy Fits Galaxy is the right choice when transparency, cost, and control matter more than vendor support. It is the standard platform for teaching bioinformatics, because students can see every parameter of every step and the training ecosystem is exceptional. The Galaxy Training Network (GTN) publishes free, community-maintained tutorials covering dozens of analysis topics, which makes Galaxy the lowest-friction entry point into cloud bioinformatics for a student or a lab without dedicated computational staff. It is also the right choice when your data cannot leave your institution, since self-hosting keeps everything inside your firewall. ## Comparing the Criteria That Decide Real Choices ### Cost Model ![Three-column comparison of Terra, DNAnexus and Galaxy on platform fee, cloud bill, governance and self-hosting.](/article-images/illustrations/terra-vs-dnanexus-vs-galaxy-cost-and-governance.webp) The three platforms charge in fundamentally different ways, and this is often the deciding factor. Terra is free to use as a platform. You pay Google Cloud for the compute and storage your work consumes, billed through your Terra billing project. A small analysis project might cost a few dollars of cloud time, while a whole-genome cohort project can cost thousands. The platform fee is zero, which makes Terra attractive for grant-funded academic work, but you must understand cloud billing to avoid surprises. Terra provides cost controls and budget alerts within the billing project, but the responsibility for the bill is yours. DNAnexus is a commercial product. You pay a subscription or licensing fee for the platform plus cloud usage costs. In exchange you get support, training, and a vendor accountable for uptime and compliance. For a clinical lab or a company, this is a reasonable operating cost. For a small academic lab, it is usually not. Galaxy is free on public servers, with fair-use limits on compute and storage. Self-hosting costs whatever your hardware or cloud bill is. A lab running Galaxy on a university HPC cluster pays nothing extra beyond the cluster allocation it already has. A lab running Galaxy on AWS pays for the EC2 instances and S3 storage it uses, which is the same underlying cost model as Terra but with the platform layer also in your hands. ### Data Governance and Compliance Governance is where the difference between Terra and DNAnexus is sharpest. Terra's governance model is built around workspace-level sharing and integration with NIH controlled-access data. When a researcher is approved for dbGaP-controlled access through an NIH data resource hosted on Terra, the platform enforces that access at the workspace level. This makes Terra the natural analysis layer for NIH-funded consortia. For clinical diagnostic work, however, Terra is not positioned as a clinical product, and a lab running clinical tests needs a system designed for that regulatory context. DNAnexus is explicitly designed for regulated environments. Its compliance framework, audit trails, and access controls are built for customers handling patient data under HIPAA and similar frameworks, and its clinical deployments are a core part of its business. If your platform choice is driven by a compliance officer, a regulatory submission, or a clinical accreditation requirement, DNAnexus is the platform among the three that is purpose-built for that conversation. Galaxy's governance depends entirely on the deployment. A public server has its own terms of use, and most public servers explicitly state that they are not for sensitive data. A self-hosted Galaxy instance can be locked down as tightly as your institution requires, which makes it a viable option for sensitive data when the institution controls the infrastructure. ### Workflow Languages and Reproducibility Reproducibility in cloud bioinformatics comes from two things: pinned software versions and recorded analysis steps. Terra pins software through Docker containers specified in WDL. The GATK best-practice workflows on Terra are versioned and published, so a result produced today can be reproduced with the same pipeline version later. The WDL-plus-Cromwell combination is mature and battle-tested at production scale. DNAnexus pins software through its app and applet system, where each tool specifies its execution environment. The platform records every job's inputs, outputs, and execution details, which supports the audit trails that regulated environments require. Galaxy records every step in a history, including tool versions and parameters, and a workflow captures that record for reuse. Galaxy's approach to reproducibility is arguably the most visible of the three, because a student can click through a shared history and see exactly what was done. The underlying principle is the same one that motivated web-based platforms like MorphoBank, which enable teams to record and share data and hypotheses in a persistent, community-available web environment rather than in files on individual machines [1]. ### Scaling and Compute All three platforms scale to large workloads, but the mechanics differ. Terra scales through Google Cloud, autoscaling virtual machines up to the limits of your billing account. Very large cohort analyses run by Broad production teams execute on the same infrastructure available to any Terra user. Terra's expansion to AWS through AnVIL extends this to Amazon Web Services infrastructure, which matters for teams with AWS commitments. DNAnexus scales across its supported clouds, and its large deployments, such as the UK Biobank platform, demonstrate population-scale throughput. The platform manages the orchestration, and the customer's job is to configure and pay for it. Galaxy scales as far as the infrastructure behind it. A public server has fair-use limits. A self-hosted instance on a university HPC cluster can scale to thousands of cores through the cluster's scheduler. A self-hosted instance on AWS can scale as far as the budget allows. The scaling ceiling is yours to build, not the platform's to grant. ### Collaboration and Sharing The historical problem that cloud platforms solve is that single-user, file-based desktop software is unsuitable for real-time, team-based collaborative work [1]. All three platforms address this, in different ways. Terra's collaboration model is the workspace. Sharing a workspace shares data references, workflows, notebooks, and access settings as one unit. Groups and domains control who can see what. For a team analyzing a shared cohort, this is efficient. DNAnexus's collaboration model is the project, with granular permissions per user or group. Large organizations use this to separate clinical, research, and development work while keeping data in one governed environment. The platform also supports the kind of media-rich, [structured data](/blog/data-analysis/what-is-structured-data) recording that web-based scientific databases pioneered, an approach described in the phylogenetics literature as essential for teams recording homology hypotheses with images and sharing and archiving them [1]. Galaxy's collaboration model is the shared history and the shared workflow. A researcher can publish a history or a workflow, and anyone can rerun it on their own data. Public Galaxy servers also function as community hubs, and the training ecosystem amplifies this. For a team spread across institutions, sharing a Galaxy workflow is often the fastest way to standardize an analysis. ### Ecosystem and Training Terra's ecosystem is anchored by the Broad Institute's pipelines and the NIH data resources that use it. If your science is GATK-based, the ecosystem is unmatched. Documentation is thorough, and the learning curve is moderate if you have some command-line background. DNAnexus's ecosystem is anchored by its customers and its professional services. The vendor provides onboarding, training, and support, which is a real benefit for an organization without deep computational staff. The dx toolkit documentation is complete, and the platform's own documentation is enterprise-grade. Galaxy's ecosystem is the largest and most open of the three. The Galaxy Training Network publishes free tutorials on an extraordinary range of topics, the Tool Shed hosts thousands of community-contributed tools, and the public servers give anyone a free starting point. The Galaxy community also maintains bridges to other domains, including the phenomics and phylogenetics space where web-based infrastructure for media-rich data has developed more slowly than in genomics [1], and Galaxy is one of the platforms filling that gap. ## Worked Scenarios ### Scenario 1: A Research Lab Running GATK Best Practices A university lab has whole-exome sequencing data for 200 samples and wants to call germline variants using GATK best practices. The lab has no dedicated bioinformatician and no existing cluster. The right answer is Terra. The GATK best-practice workflows are published and ready to run, the lab creates a billing project, links it to a Google Cloud account, uploads the FASTQ files, and launches the pre-built workflow. Total platform cost is zero. The cloud bill is the only cost, and it scales with the actual work. The alternative, DNAnexus, would add a commercial fee the lab does not need, and Galaxy would require the lab to build and maintain the pipeline wrappers itself. ### Scenario 2: A Clinical Sequencing Laboratory A hospital molecular diagnostics lab runs exome sequencing as a clinical test. Every report must be traceable to a documented software version, every change to the pipeline must be controlled, and patient data must be handled under HIPAA. The right answer is DNAnexus. The compliance framework, audit trails, access controls, and vendor support are designed for exactly this environment. Terra is not positioned as a clinical diagnostic platform, and a self-hosted Galaxy instance would put the entire compliance burden on the lab's own staff. The commercial cost is justified by the regulatory context. ### Scenario 3: A University Teaching Course An instructor is teaching a graduate [bioinformatics course](/blog/careers/bioinformatics-courses-and-certifications-a-practical-guide) to 30 students who have never used a command line. The course covers RNA-seq analysis from raw reads to differential expression. The right answer is Galaxy on a public server such as usegalaxy.org or usegalaxy.eu. Students work through the graphical interface, see every parameter, and follow free Galaxy Training Network tutorials. The instructor can share a workflow and a dataset, and every student reruns the same analysis. Terra would require each student to manage a Google Cloud billing account, which is a poor teaching setup, and DNAnexus is not accessible to a class at zero cost. ### Scenario 4: A Consortium Sharing Controlled-Access Data An NIH-funded consortium hosts genomic and phenotypic data for hundreds of approved researchers across many institutions. The data are controlled-access, and the consortium must enforce who can analyze what. The right answer is Terra. The AnVIL and BioData Catalyst ecosystems use Terra as their analysis layer precisely because workspace-level access controls integrate with NIH controlled-access data governance. Researchers bring their analysis to the data, and the consortium does not ship data around. DNAnexus could build a comparable environment, and does for other large consortia, but for NIH-funded resources Terra is the established pattern. ### Scenario 5: A Lab Without Cloud Budget That Wants Transparency A small lab has a university HPC cluster allocation and wants a reproducible, shareable analysis environment for its metagenomics work. The lab has no grant line for platform fees and no compliance requirements. The right answer is a self-hosted Galaxy instance on the lab's cluster. The platform is free, the jobs run on the allocation the lab already has, every analysis is recorded in a history the lab owns, and the Tool Shed provides the [metagenomics tools](/knowledge/bioinformatics/metagenomics-tools-a-practical-guide-to-software-and-pipelines). If the lab later needs cloud burst capacity, the same Galaxy instance can be extended to AWS or another cloud, which connects the self-hosting path to the broader AWS genomics ecosystem without a platform migration. ## Common Mistakes and Limitations **Mistake 1: Confusing the platform cost with the cloud cost.** Terra and Galaxy are free platforms, but the compute and storage underneath are not. A researcher who launches a whole-genome workflow on Terra without checking the estimated cost can generate a large Google Cloud bill. Always review the cost estimate Terra shows before launching, and set budget alerts on the billing project. The same applies to self-hosted Galaxy on a cloud provider. **Mistake 2: Choosing a platform before choosing the data.** If your target dataset is hosted on a specific platform, that decision is made for you. Data hosted in AnVIL or BioData Catalyst is analyzed on Terra. Data in the UK Biobank Research Analysis Platform is analyzed on DNAnexus. Downloading controlled-access data to another platform may violate the data access agreement, so check the terms before planning the analysis. **Mistake 3: Treating Galaxy public servers as a production environment.** Public Galaxy servers are free and generous, but they enforce fair-use limits and are not appropriate for sensitive data or for very large production workloads. They are a superb starting point and teaching environment, not a substitute for a self-hosted instance or a cloud platform when the workload grows. **Mistake 4: Underestimating the WDL learning curve on Terra.** Running pre-built GATK workflows requires little WDL knowledge, but modifying a workflow or writing a new one does. Teams that assume Terra requires no coding are often surprised when they need to customize. Budget time for WDL, or plan to use only published workflows. **Mistake 5: Assuming DNAnexus is only for large enterprises.** While DNAnexus is known for population-scale deployments, its project model and dx command-line interface work for smaller teams as well. The real question is whether the subscription and support model fits the budget, not whether the platform is too big. **Mistake 6: Ignoring data egress.** Moving data out of a cloud provider can cost more than moving it in. A team that uploads terabytes to one platform and later wants to move to another should plan for egress costs and time. This is a general property of cloud bioinformatics, not a flaw in any one platform. **Limitation.** Platform choice is an infrastructure decision, and the right answer depends on your data access agreements, your compliance requirements, your budget, and your team's skills. The scenarios above are patterns, not prescriptions, and individual projects should be evaluated against their own constraints before committing. ## Frequently Asked Questions ### Is Terra free to use? Yes, the Terra platform itself is free, but you pay the underlying Google Cloud compute and storage costs through a Terra billing project, so the total cost depends on how much analysis you run. ### Can Galaxy run on AWS? Yes, Galaxy is open-source software that can be self-hosted on AWS or any other cloud provider, on a university HPC cluster, or on a single server, and public Galaxy servers also remain free for fair-use work. ### Which is better for clinical work, Terra or DNAnexus? DNAnexus is the better fit for clinical work because it is a commercial platform built with the compliance features, audit trails, and vendor support that regulated clinical laboratories require, while Terra is positioned as a research platform. ### Do I need to know how to code to use these platforms? Galaxy requires no coding for point-and-click analysis, Terra requires no coding to run pre-built workflows but WDL knowledge for customization, and DNAnexus offers both a graphical interface and a command-line interface for users who prefer it. ### Can I move workflows between platforms? Some portability exists through open standards such as the Common Workflow Language, which Galaxy supports, but each platform has its native workflow format, so plan for some rework when moving between Terra, DNAnexus, and Galaxy. ### What is the difference between Terra and DNAnexus for data storage? Terra stores data references in workspaces tied to Google Cloud storage, with access controlled at the workspace level, while DNAnexus stores data in projects on AWS, Azure, or Google Cloud with granular per-project permissions, and the practical difference is governance and cloud provider rather than storage capability. ## Sources 1. [MorphoBank: phylophenomics in the "cloud".](https://pubmed.ncbi.nlm.nih.gov/34875801/)