11 graph databases to evaluate for low-latency GraphRAG in 2026

Picking a graph database for Graph Retrieval-Augmented Generation (GraphRAG) is never just about traversal speed. The wrong fit shows up later, in stale results, slow context assembly, or permission leaks during retrieval.

Graph retrieval is extra work, and it only pays off when relationships in the data actually improve the answer over a simpler vector or lexical baseline. Once you cross that line, the real test is whether the database can handle bounded multi-hop expansion, filtering, and ranking, not just basic lookups.

At scale, compare memory-first, disk-backed, multi-model distributed, and object-store-native architectures. The full context-assembly path matters more than any single stage. Indexing, retrieval, filtering, context construction, and generation all add latency, and a database that's fast at one stage can still be slow overall.

This guide breaks down 11 graph databases against that full path, so you can shortlist the right one for your workload instead of chasing benchmark numbers alone.

TL;DR

• For a mature, general-purpose baseline: choose Neo4j when the Cypher ecosystem, hybrid retrieval, and tooling depth matter most.

• For low-latency or streaming workloads: choose FalkorDB or Memgraph, built for in-memory execution and real-time graph updates.

• For persistent, tenant-scoped GraphRAG context: choose HydraDB, an object-store-native graph database with managed isolation, temporal context, and hybrid retrieval. HelixDB takes a similar approach but is still early in production validation.

• For AWS-mandated infrastructure: choose Amazon Neptune, a managed service supporting both RDF and property graphs.

• For semantic, ontology-governed workloads: choose GraphDB or Stardog, built around RDF, SPARQL, and reasoning.

• For GraphQL-first development: choose Dgraph, a distributed graph database built around GraphQL and DQL.

• For graph as one part of a larger application: choose ArangoDB, a multi-model database combining documents, graphs, and key-value data.

• For multimodal retrieval: choose ApertureDB, built around images, video, and embeddings.

• For flat, static corpuses: skip graph complexity and use vector or BM25 retrieval alone.

Quick comparison: Low-latency GraphRAG databases at a glance

Database architectures handle storage, compute, and retrieval differently. Object-store-native designs separate durable storage from disposable compute. In-memory designs trade active dataset size for traversal speed.

Evaluating low-latency GraphRAG databases

A database that performs well on isolated graph traversal may still add latency elsewhere in the GraphRAG retrieval path. Evaluate each option based on context assembly, freshness, persistence, retrieval capabilities, and governance.

This shortlist focuses on databases with a clear fit for real-time GraphRAG across one or more of these areas. it'sn't intended to cover every graph database that could support a GraphRAG workload. 

Bounded context assembly for GraphRAG

Real-time GraphRAG requires architectural capabilities that support the full context-assembly path. A database needs to plan the query, find the right seed nodes, expand outward within a bounded number of hops, then filter and index the results, all while handling concurrent requests without slowing down.

Freshness latency and temporal correctness

A successful write doesn't always mean new data is immediately available to queries. Measure how long updates take to become visible, how often reads return stale data, and how quickly corrections or retractions propagate. For time-sensitive GraphRAG, also check whether the database can answer current-state and as-of queries accurately.

Durable persistence and operational model

Where and how a database stores durable data affects scaling, backups, and recovery. Some systems keep active data in memory or on local disk, while others use object storage or distributed storage. Compare these models against your durability and recovery requirements.

Retrieval architecture and API support

Retrieval architectures combine native database capabilities, documented integrations, and customer-built orchestration. Real-time context assembly requires comparing graph, vector, lexical, metadata, and temporal retrieval capabilities against the APIs, drivers, and ecosystem integrations each database supports.

Authorization, provenance, and governance

Permission-aware GraphRAG requires strict tenant isolation and filtering during bounded expansion. It also needs metadata filters, access controls, provenance patterns, and auditability.

Option 1: HydraDB

Best for

• Real-time GraphRAG workloads where bounded multi-hop relationships, temporal facts, tenant scoping, and hybrid retrieval all matter.

• Teams that want graph-native context infrastructure rather than a finished company brain, extraction engine, ontology tool, or agent framework.

Overview

HydraDB is an object-store-native graph database and graph-native context infrastructure for AI. It decouples compute and storage, using S3-compatible storage as the durable source of truth and disposable memory/NVMe state for traversal and indexing.

Customers control extraction logic, ontology semantics, authorization policy, agent orchestration, and final application behavior.

Key features

• Object-store-native durability: Graph records, write-ahead logs, manifests, coordination objects, and traversal indexes live in S3-compatible object storage.

• Graph storage, indexing, and bounded traversal primitives: The open core provides the primitives needed to store, index, and traverse multi-hop relationships within bounded queries.

• Managed hybrid retrieval primitives: The platform runs ingestion asynchronously and combines metadata filtering, dense and BM25 retrieval, optional graph enrichment, and application-side LLM response generation.

• Scoping and temporal controls: The open core authorizes hierarchical graph scopes and applies bounded-operation controls. The managed platform isolates customers or environments in separate databases, scopes collections within a database, and returns current, as-of, range, or upcoming edge facts for temporal queries.

• Qualified openCypher support: The database supports a practical openCypher subset and Neo4j drivers over the Bolt 5.1 through 5.4 surface.

Pricing

• Ship plan: Free with unlimited API calls.

• Surge plan: $25 per month plus usage, with storage at $0.50 per GB per month.

• Scale plan: $399 per month plus usage, with storage at $0.25 per GB per month.

• Enterprise plan: Custom pricing, with BYOC or fully self-hosted deployment.

Key strengths

• Since durable storage and query compute run separately, the graph can keep growing without forcing a proportional increase in provisioned compute.

• Temporal context is added on top of a result rather than folded into its relevance score, so older or superseded facts don't quietly outrank what's most relevant now.

Where the fit breaks down

• Small, flat, static corpuses work well with pure vector or lexical retrieval alone without graph traversal.

• Workloads requiring full Neo4j compatibility or unrestricted Cypher commands encounter limits within the practical openCypher subset.

• Teams looking for a turnkey application, extraction pipeline, ontology system, or finished agent memory product need a different product category.

• Asynchronous context ingestion can complete parsing and embedding before graph construction finishes. An accepted upload is not immediately queryable.

Option 2: Neo4j

Best for

• Teams with existing Cypher logic, Neo4j skills, visualization workflows, or enterprise graph deployments.

• Buyers that value ecosystem maturity, first-party GraphRAG tooling, and broad developer familiarity.

Overview

Neo4j runs as either self-managed software or through the managed Aura service. It’s commonly used for operational graph workloads.

Its first-party GraphRAG package includes RAG, knowledge-graph-building, and pipeline components. Application authorization, provenance requirements, and end-to-end orchestration still depend on the deployed architecture.

Key features

• Native labeled property graph storage and the Cypher query language.

• First-party Neo4j GraphRAG Python package for orchestrating retrieval.

• Native vector indexes for similarity search.

• Full-text indexes and hybrid retrieval patterns that combine graph, vector, and lexical capabilities.

• Aura managed cloud deployment options alongside comprehensive visualization and graph data science tooling.

Pricing

• Aura Free tier is available at $0.

• Aura Professional is priced at $65 per GB-month with a 1 GB minimum capacity requirement.

• Aura Business Critical is priced at $146 per GB-month with a 2 GB minimum capacity requirement.

• Self-managed enterprise licensing requires direct sales engagement.

Key strengths

• Deep documentation across Cypher, Bolt, APOC, and Graph Data Science shortens onboarding.

• Tooling varies by edition, so teams can start light and upgrade only when needed.

• A solid baseline for testing whether a GraphRAG workload even needs anything more specialized.

Where the fit breaks down

• Buyers must verify procedures, plugins, graph size, deployment models, and Aura tier constraints.

• Neo4j requires workload-specific memory and cache sizing for heap, page-cache, and vector-index allocations.

• Migration from Neo4j to other Cypher-like systems requires query and procedure review.

• Freshness-sensitive workloads should test vector index visibility and same-transaction behavior for just-written data.

Option 3: Amazon Neptune

Best for

• Organizations mandated to use AWS-managed infrastructure.

• Applications that call for both RDF/SPARQL and property-graph support without running two databases.

Overview

Inside AWS, Neptune handles graph workloads as a fully managed graph database service. It supports semantic graph and property graph workloads through SPARQL, Gremlin, and openCypher.

For managed GraphRAG, Amazon Bedrock Knowledge Bases uses Neptune Analytics for graph and vector storage. Teams can also build custom GraphRAG architectures using Neptune services and other AWS components.

Key features

• Multi-model graph support for RDF and property graph workloads.

• SPARQL, Gremlin, and openCypher query language surfaces.

• Provisioned and serverless deployment options with up to 15 replicas.

• Neptune Analytics provides in-memory graph analytics.

Pricing

• Pricing depends on provisioned instances or Neptune Capacity Units.

• Storage and I/O costs apply based on consumption.

• Standard and I/O-Optimized modes require workload-specific modeling.

• Neptune lacks a single flat tier. Costs scale directly with AWS infrastructure usage.

Key strengths

• AWS-native security, networking, monitoring, backup, and availability integrations can fit AWS-standardized organizations.

• Managed operational models separate storage from compute and handle failover, reducing database administration overhead.

Where the fit breaks down

• Not suitable for teams that require self-hosted or non-AWS-managed deployments.

• Neptune costs depend on workload and require modeling representative I/O, backup, and capacity charges.

• GraphRAG retrieval orchestration, lexical retrieval, authorization, and provenance design depend on the selected AWS architecture and should be evaluated for the required workflow.

• openCypher implementation differences require query testing for teams migrating from Neo4j.

Option 4: GraphDB from Graphwise

Best for

• RDF-heavy semantic knowledge graphs in scientific, biomedical, regulatory, or ontology-governed environments.

• Projects where standards-based reasoning and inference matter more than Cypher-style development.

Overview

GraphDB from Graphwise is built around RDF for semantic knowledge graphs. It centers on W3C standards such as RDF, SPARQL, OWL, and SHACL, and fits GraphRAG best when retrieval depends on governed ontologies, semantic inference, and source-linked structured facts.

Key features

• RDF triple storage and SPARQL querying interfaces.

• OWL and RDFS reasoning and inference capabilities.

• SHACL validation support for strict data governance.

• Semantic repository management and ontology tooling.

• Similarity plugins and RDF embedding integrations for semantic GraphRAG patterns.

Pricing

• A free option is limited to a single core and requires a valid license.

• Paid enterprise editions require custom quoting or qualification-based licensing.

• Paid tier pricing details don't appear on standard pricing pages.

Key strengths

• Ontology governance and inferred relationships run as native database functions rather than application-layer logic.

• A natural fit for teams already committed to RDF and SPARQL rather than property-graph tooling.

Where the fit breaks down

• Not a fit for teams expecting JSON-like Labeled Property Graph development or Cypher-first workflows.

• Teams must verify real-time GraphRAG latency against the actual retrieval path, accounting for inference overhead.

• While GraphDB provides semantic-similarity search and a Lucene full-text connector, embedding-based vector search requires integrating separate Enterprise Elasticsearch or OpenSearch connectors.

• End-to-end LLM orchestration and permission-aware context assembly still require evaluation of the selected edition, connectors, and application architecture.

Option 5: HelixDB

Best for

• Workloads that require graph, vector, and full-text capabilities with object-store durability.

• GraphRAG or AI memory workloads that benefit from keeping graph and vector retrieval in one engine.

Overview

HelixDB is a graph database providing graph, vector, and full-text capabilities. It uses an object-storage durability model alongside client DSLs and vendor benchmark materials targeting graph-vector workloads.

Key features

• Graph storage and traversal capabilities designed for relationship-rich retrieval patterns.

• Vector retrieval capabilities for embedding-based lookup.

• Full-text search capabilities for lexical retrieval alongside graph and vector signals.

• Object-storage durability model with NVMe and memory caching.

• Client DSLs supporting Rust, TypeScript, Go, and Python.

Pricing

• Plans start at $5 according to the homepage.

• Viewing the complete pricing schedule requires signing in.

• Production pricing, support levels, and enterprise tiers require direct engagement and custom quoting.

Key strengths

• Combining graph, vector, and full-text capabilities reduces the need to coordinate separate retrieval systems for GraphRAG.

• Keeping durable state in object storage lets storage and compute scale independently, without giving up graph-vector query performance.

• Native graph-vector access allows vector prefiltering within the query path.

Where the fit breaks down

• HelixDB doesn’t publish a complete plan-and-limit matrix on its public pricing page.

• Vendor-published benchmark materials omit cold start, insertion, memory, operations, and vector limits, so teams should test the intended deployment topology under representative production workloads.

• Authorization, tenancy, provenance, and production support maturity require direct validation.

Option 6: Dgraph

Best for

• Distributed graph-backed applications where GraphQL is the preferred developer interface.

• Transactional applications built around graph-shaped data.

Overview

Dgraph is a graph database designed around GraphQL and DQL APIs. It's currently maintained by Istari Digital, which acquired the project from Hypermode in October 2025, with the latest release in the v25 series.

Dgraph targets GraphRAG buyers connecting graph data directly to application APIs and GraphQL schemas.

Key features

• Native GraphQL API generation from schema definitions.

• DQL query language for internal graph access.

• GraphQL vector similarity directives including @embedding and @search with HNSW indexing.

• JSON and RDF data representations.

• Distributed architecture designed for sharding and replication capabilities.

Pricing

• Dgraph's public documentation doesn't publish a standalone database price list.

• A new Dgraph cluster enables enterprise features for a 30-day trial. Continued use of those features requires an enterprise contract.

• Pricing tied to Istari Digital's broader platform shouldn’t be treated as Dgraph database pricing on its own.

Key strengths

• Schema-defined GraphQL APIs can fit teams standardized on GraphQL.

• Current vector similarity directives support a direct GraphRAG evaluation path beyond basic graph querying.

Where the fit breaks down

• Teams standardized on Cypher, SPARQL, or Gremlin need to account for query migration to GraphQL or DQL.

• Evaluate lexical retrieval, provenance, and GraphRAG orchestration against the selected application architecture.

• Distributed, managed, and enterprise operational claims require validation against Dgraph's current packaging under Istari Digital.

Option 7: FalkorDB

Best for

• Workloads prioritizing low-latency graph execution within an in-memory or memory-first deployment model.

• RedisGraph users looking for a compatible successor path.

Overview

FalkorDB comes from the RedisGraph lineage and is built around Sparse Matrix Algebra using GraphBLAS, targeting fast graph execution and AI agent workloads. It processes graph and vector retrieval within a single low-latency-oriented engine.

Key features

• GraphBLAS-based execution model for sparse adjacency graph operations.

• Cypher and openCypher-style query support.

• RedisGraph compatibility path.

• Vector, full-text, and range indexes natively integrated.

• Built-in GraphRAG SDK positioning and cloud infrastructure.

Pricing

• A free tier is available.

• The Startup tier begins at $73 per month for 1 GB.

• The Pro tier begins at $350 per month for 8 GB.

• Enterprise deployments require custom pricing.

Key strengths

• The GraphBLAS-based execution model is designed for low-latency traversal over sparse graph structures.

• Removes the need to bridge separate graph and vector engines for real-time retrieval.

• Existing RedisGraph deployments can migrate with less application and query rework than moving to an unrelated graph database.

Where the fit breaks down

• The active graph and indexes must be sized against the selected instance or cluster memory, while RDB and AOF provide persistence. Teams must model memory, replicas, persistence, and recovery costs for the target graph size.

• Enterprise governance, authorization, and tenant isolation require direct architectural review.

• Buyers must benchmark full context assembly, freshness, and cold restart behavior rather than isolated warm-cache traversal speed.

• Not a fit for workloads that require RDF interoperability or standards-based semantic reasoning.

Option 8: Memgraph

Best for

• Real-time streaming graph workloads.

• Cybersecurity, fraud, infrastructure, or event-driven use cases where graph state changes frequently.

Overview

Written in C++, Memgraph supports Cypher and runs in-memory transactional and analytical modes, with an on-disk transactional mode for larger datasets. It's built for real-time graph analytics, streaming ingestion, and dynamic graph algorithms.

For GraphRAG, it fits best when fresh, event-driven context matters more than semantic ontology management.

Key features

• In-memory graph execution architecture with ACID durability to disk.

• Cypher query support.

• Streaming integrations with Kafka, Pulsar, and Redpanda.

• MAGE graph algorithm library.

• Native vector search capabilities.

Pricing

• Community edition is free.

• Cloud deployment pricing depends on memory requirements.

• Enterprise features and pricing require custom engagement.

Key strengths

• Cypher query support reduces query-language friction for teams already working with Cypher-based graph systems.

• Kafka, Pulsar, and Redpanda connectors bring event streams directly into the graph for continuous updates.

Where the fit breaks down

• In-memory deployments require sizing the active graph, vectors, and indexes against available memory. The on-disk transactional mode is an option for datasets that exceed RAM.

• Stream-to-visible latency and restart recovery should be tested under representative ingestion and query loads.

• GraphRAG extraction, chunking, authorization, provenance, and LLM orchestration require customer-built solutions.

• Not a natural fit for RDF or ontology-heavy semantic knowledge graph workloads.

Option 9: ArangoDB from Arango

Best for

• Applications that need document, key-value, and graph models in one operational backend.

• Teams where graph retrieval is important but represents only one part of a broader application data model.

Overview

ArangoDB is a native multi-model database that processes queries through AQL, providing a unified language across distinct data models. The platform handles hybrid retrieval and graph-plus-vector patterns for application backends.

Key features

• Multi-model storage engines for documents, graphs, and key-value data.

• AQL query language.

• ArangoSearch and native vector search capabilities.

• SmartGraphs and SatelliteGraphs for enterprise replication and distributed queries.

• Official AI Suite and GraphRAG positioning materials.

Pricing

• ArangoDB Self-Managed uses BSL 1.1 with an Additional Use Grant that permits internal production use but restricts commercial offerings that let third parties access, create, or manage databases containing third-party-controlled data.

• Cloud and enterprise deployments require a direct pricing request.

• Exact deployment-size and tier figures don't appear on the pricing page.

Key strengths

• Handles evolving or mixed data shapes without forcing a schema redesign as requirements change.

• AQL lets applications query documents and graph relationships through the same query language.

Where the fit breaks down

• AQL adoption requires retraining and migration work for teams standardized on Cypher, SPARQL, or Gremlin.

• Specialized graph traversal, governance, vector, and search features vary across Community and Enterprise deployments.

• Multi-model breadth may add no decision value when the workload requires only a focused graph database or an RDF/SPARQL semantic graph.

• AQL queries, indexes, and concurrency behavior should be tested against the target workload.

Option 10: Stardog

Best for

• Enterprise semantic knowledge graphs, governed data fabrics, and ontology-heavy environments.

• Organizations with data scattered across siloed systems that need it unified without moving it.

Overview

Stardog is built as an enterprise knowledge graph and data-fabric platform, combining semantic modeling, virtualization, inference, governance, and querying across distributed data sources. Its approach to GraphRAG depends on ontologies, connectors, and semantic layers rather than vector proximity alone.

Key features

• RDF storage and SPARQL support.

• Virtual graph capabilities for querying external data sources.

• Semantic reasoning, rules, and inference.

• REST and SQL access patterns.

• Enterprise governance, security, and integration capabilities.

Pricing

• Stardog Free is available at no cost and is renewable for one year, but it's not open source.

• Enterprise deployments require custom pricing.

• Pricing packages depend on deployment scope and federation requirements.

Key strengths

• Virtual Graphs map supported external sources into RDF and can combine external data with a local Stardog database in one SPARQL query.

• SHACL validation and guard mode can enforce configured data-quality constraints when data changes.

Where the fit breaks down

• Virtual graph behavior depends on the availability and capabilities of connected source systems and their connectors.

• The platform has a broader scope than focused GraphRAG infrastructure, which adds complexity when semantic modeling, virtualization, and governance aren't required.

• Remote federation and semantic reasoning can add latency, so teams should test the full retrieval path against their GraphRAG response targets.

• Less suited to teams looking for a simple, low-latency, memory-first local graph engine.

Option 11: ApertureDB

Best for

• Multimodal AI systems where images, video, embeddings, annotations, and relationships all matter.

• Computer vision and deep learning pipelines that need connected metadata around media assets.

Overview

ApertureDB centralizes media objects, embeddings, and relationship metadata in one system, built specifically for managing and searching multimodal visual data. For GraphRAG, it fits workloads that depend heavily on multimodal retrieval rather than general-purpose text knowledge graphs.

Key features

• Native support for visual media objects including images, video, and audio.

• Vector search capabilities using FAISS for embedding-based retrieval.

• Relationship metadata connecting media assets, labels, annotations, and derived features.

• JSON command API and unified query structure.

• ACID transactional behavior and in-memory graph operations.

Pricing

• A 30-day free option is available.

• The Basic tier costs $0.33 per hour for an 8 GB, 2 CPU profile.

• The Standard tier costs $1.29 per hour for a 32 GB, 8 CPU profile.

• The Premium tier costs $4.00 per hour for a 48 GB, 10 CPU profile.

• Enterprise pricing is custom.

Key strengths

• Keeps binary media, FAISS-based vector search, and graph-connected metadata behind one JSON command API, reducing the number of systems a multimodal pipeline needs to coordinate.

• Graph relationships between assets, labels, and annotations stay queryable alongside the vector search, rather than living in a separate metadata store.

Where the fit breaks down

• ApertureDB is purpose-built for multimodal data, so it may be less suitable for text-heavy property-graph or RDF workloads.

• Its documented query surface is a JSON command API rather than Cypher or SPARQL, so adopting it requires application work for teams standardized on those languages.

• Teams should map ApertureDB's available access controls and governance capabilities against their specific provenance and tenant-isolation requirements.

• Throughput and stability should be tested against representative asset sizes, relationship depth, and concurrency.

How to choose the right low-latency GraphRAG database

Step 1: Define your GraphRAG must-haves

Start with a simpler vector or lexical baseline that fits the direct-lookup workload. Add graph infrastructure only when relationships, provenance, permissions, changing state, or multi-hop evidence improve results enough to justify the added complexity. Set budget and ROI expectations upfront.

Step 2: Evaluate fit with your retrieval and data stack

Map the systems involved in retrieval, including vector search, lexical search, metadata filters, authorization services, source systems, orchestration layers, LLM gateways, and observability. Separate the database's native capabilities from integrations and customer-built components.

Step 3: Test end-to-end context assembly

Run proof-of-concept queries on your own data. Measure seed lookup, bounded expansion, filtering, context assembly, and final answer generation. Don't rely on isolated warm-cache traversal alone.

Step 4: Validate freshness, provenance, and authorization

Test concurrent writes, changing facts, temporal queries, source attribution, tenant boundaries, and permission filters. Measure write-to-visible latency across graph, vector, and metadata indexes. Report p50, p95, and p99 latency alongside the stale-read rate. Confirm the system prevents unauthorized nodes, edges, chunks, or embeddings from leaking during multi-hop graph expansion.

Step 5: Model total cost of ownership

Calculate the full cost of licensing, compute, storage, I/O, backups, and overages. Include migration, retraining, maintenance, vector memory, and future switching costs.

Conclusion

A credible evaluation tests each database against the same workload, constraints, and answer-quality targets. Compare the results with a direct vector baseline and measure the full context-assembly path rather than isolated retrieval speed.

Book a demo to evaluate whether HydraDB's object-store-native graph database and managed context platform fit your deployment.

FAQ

What is the best low-latency graph database for real-time GraphRAG?

No universal best option exists. Neo4j is the mature baseline. FalkorDB and Memgraph fit memory-first or streaming workloads. HydraDB is built for object-store-native, temporal GraphRAG at the tenant level.

When should I use a graph database instead of vector search for GraphRAG?

Use a graph database when relationships, multi-hop evidence, permissions, provenance, or changing state materially improve retrieval. For flat and static corpuses, vector or BM25 retrieval may be simpler and sufficient.

What should I benchmark when choosing a GraphRAG database?

Benchmark the full context-assembly path, including seed lookup, bounded expansion, filtering, ranking, write-to-visible freshness, permission enforcement, and final answer latency. Don't rely only on isolated traversal benchmarks.

Which graph databases are best for in-memory or streaming GraphRAG workloads?

FalkorDB documents a GraphBLAS-based, memory-first graph engine, while Memgraph documents stream connectors and in-memory transactional and analytical modes. Evaluate active dataset size, storage mode, freshness latency, restart behavior, and memory cost on the intended deployment.

Which graph databases are best for semantic or ontology-heavy GraphRAG?

Choose GraphDB when RDF/SPARQL and materialized RDFS or OWL reasoning are decisive. Choose Stardog when RDF/SPARQL, query-time reasoning, or Virtual Graph federation is decisive.

How does HydraDB fit into real-time GraphRAG?

HydraDB combines an object-store-native graph database with a managed platform layer, tenant isolation and collection scoping, hybrid retrieval, and temporal context. It fits best when relationship-rich context retrieval needs all of those working together rather than assembled separately.