Skip to content
Platform / Architecture & Deployment

Built for scale. Deployed on your terms.

DataWalk brings graph, relational and search analytics together in one memory-efficient, distributed platform. Analyze connected data at enterprise scale without assembling separate analytical engines. Deploy on infrastructure you control.

What happens when your graph reaches terabyte or even petabyte scale?

INFRASTRUCTURE COST GRAPH SIZE PERFORMANCE CEILING 495 Billion Objects One Single-State
01 · The cost of scale

Complex analysis doesn’t get done.

As connected data grows, the compute and memory needed for complex analysis can become too expensive. Teams limit the questions, or the queries never finish.

DataWalk stores relationships once and reuses them, so queries need less compute and memory than rebuilding connections each time.

That means larger, faster analysis with less infrastructure cost.

Why DataWalk needs less compute and memory

DataWalk calculates and stores relationships as data enters the knowledge graph, then keeps supported relationships up to date. Queries use those established connections instead of reconstructing them for every question.

Traversals work on compact sets of references and fetch attributes only when results are used, so the full graph never has to sit in memory.

How storage and execution are separated

Persistent storage Object storage

Holds the full graph: its data and relationships.

Cache Worker-local disk

Keeps frequently used data close to each worker.

Execution CPU and RAM

Runs queries, calculations, imports and refresh.

These are resource roles, not stages that data passes through in sequence. Storage, cache, and compute are sized for the workload.

02 · The cost of complexity

Multiple engines. More work to keep them in sync.

Separate analytical stores mean more pipelines, more copies to reconcile, and more potential failure points for your team to manage.

Graph, relational and search analytics use the same data. Start with a search, follow connections across sources, and count or filter what you find in the same analysis. The search index lives inside the DataWalk database, so your team has no separate search service to run or keep in sync.

Fewer systems to integrate. Fewer copies to reconcile. Less engineering to maintain.

What shared analytical state removes

When graph, relational, and search engines each maintain their own analytical copy, engineers manage change-data-capture pipelines, reconciliation, backfills, permission enforcement, and recovery workflows to keep them aligned.

DataWalk removes the synchronization needed solely to keep those separate analytical stores consistent. Ingestion from source systems, caches, backups, and external integrations still require operation.

03 · The cost of change

New questions become new data projects.

A new question, data source, or business definition can mean pipeline changes, custom refresh scripts, and engineering work before analysis can begin.

DataWalk lets your team change queries and configure the ontology. Graph Consistency manages supported dependencies as the data changes.

Less engineering to maintain. Less rebuilding when requirements change. More control for your team.

Less engineering when data and requirements change

A new requirement does not always need a new data project. When the data and relationships are already available, your team can answer a different question by changing the query. When data or metadata must change, the engineering work matters.

Data changes

New and updated data can trigger chains of dependent relationships, rules, and calculations. Engineers must maintain custom scripts, coordinate execution order, and rerun calculations whenever upstream data changes.

DataWalk’s Graph Consistency manages declared dependencies and keeps supported derived relationships and facts up to date. Your team has less custom refresh logic to build and maintain.

Metadata changes

Adding attributes, changing definitions, or evolving the ontology can force engineers to modify ingestion code, rebuild mappings, and reprocess existing data.

Your team can often add an attribute or change a business definition directly in DataWalk’s ontology and keep using the graph you’ve already built. The work is limited to the mappings and calculations that depend on the change.

In an alternative stack, the same change can require engineers to rewrite ingestion code, rebuild mappings, and reprocess existing data.

Performance evidence

Built for petabyte-scale ambition.
Proven at enterprise scale.

Review the measured results and test conditions, then evaluate the workloads that matter to your organization.

495 billion

Objects loaded and indexed in a single environment

Under 6 hours

To load and index 13 TB, end to end

Under 5% RAM

Memory use stayed below 5% on each server during a 20-query test that built a 360° view of 2,500 objects.

Query performance

Request-latency result, relationship depth and test conditions are published with the approved traversal benchmark.

Deployment

Deploy DataWalk on your infrastructure.

Run DataWalk in your cloud, on premises or in an air-gapped environment. Your team controls where the data resides, how the platform is secured and how the infrastructure is operated. DataWalk does not collect telemetry from your deployment, and the platform sends no telemetry back to DataWalk. Size compute and storage for your workloads.

Supplied by DataWalk Provided and operated by your organization
DataWalk provides
Container images
Helm charts
Releases and updates
Delivered from DataWalk’s image registry, or by controlled transfer for air-gapped sites.
Your infrastructure
Container image registryReceives and stages DataWalk images.
DevOps teamInstalls, upgrades and operates the deployment.
Kubernetes cluster · DataWalk running
Each tier scales independently
ApplicationUser-facing services and APIs
App CenterCustomer applications and integrations
DatabaseDistributed analytical engine
Compatible object storagePersistent data, outside the cluster, accessed by the Database tier
Run it in one of
Public cloudYour cloud account. AWS, Azure or Google Cloud.
On-premisesYour Kubernetes platform, such as OpenShift, Rancher or VMware vSphere.
Air-gappedAn internal registry and controlled transfer of software and updates.

Plan your deployment.

Infrastructure requirements

Prepare Kubernetes clusters, compatible object storage, a container image registry and an operations team with Kubernetes experience. Plan at least one non-production environment alongside production.

Sizing depends on data volume, query workload and concurrency. DataWalk provides reference sizing for development, test and production during deployment planning.

Installation and updates

DataWalk supplies container images and Helm charts. Your team stages the images in your registry, then installs and upgrades DataWalk in your Kubernetes environment using DataWalk’s installation guidance.

Operations and responsibility

In the standard model, your organization manages the Kubernetes infrastructure, deployment automation and ongoing operations, including monitoring, backups and upgrades. DataWalk provides installation guidance and administrator training.

In production
Multinational bank and insurer Approximately 7 billion transactions · 90 billion connections

Perpetual KYC. Calculated attributes feed automated risk rating and machine learning.

Federal law enforcement 2 billion nodes · 2 billion edges

Cryptocurrency investigations. Runs fully air-gapped, correlating blockchain data with internal case data.

FAQ

Questions from architects.

Find your answer

View All
How is DataWalk’s architecture different to a stack of separate analytical systems?
When you assemble separate analytical systems, your engineering team owns the work between them: maintaining pipelines, reconciling copies, coordinating permissions, and adapting integrations whenever sources or requirements change. DataWalk runs graph, relational, and search analytics against the same stored analytical state, with shared access controls and lineage. That reduces synchronization work and integration dependencies. New applications and use cases reuse that foundation, so your engineers can focus on business logic rather than repeatedly building and maintaining the underlying infrastructure. Your team still manages source ingestion and deployment operations.
How does DataWalk differ from a memory-dependent graph architecture?
The stored graph is held in object storage, not in RAM. Traversals operate on compact sets of object references, and attributes are retrieved when the result is used, so analysis does not depend on holding the whole graph in memory.
Does single-state mean a single server?
No. Graph, relational and search share one stored analytical state, including the search index inside the database. Database workers share the computation across the cluster. Caches, backups and source records still exist as separate copies.
Do you run a separate search engine?
No. The search index lives inside the DataWalk database, so there’s no separate search service to run or keep in sync. Start with a search, then follow relationships or narrow the results in the same analysis.
Why does DataWalk ingest data rather than query every source in place?
Preparing relationships in the knowledge graph makes repeated connected analysis practical: searches and traversals run over connections that already exist. The trade-off is ingestion, storage and refresh work. Source systems remain in place.
How do changes to data and relationships become available?
After ingestion and the required dependency refresh finish. Set freshness targets for the full cycle.
How does DataWalk work with our security controls?
DataWalk integrates with enterprise identity providers through SAML, LDAP, Kerberos or x509, depending on configuration. Role- and attribute-based permissions apply during traversal. DataWalk logs user access, record views and exports for audit. Records retain lineage to their sources.
How should we size and evaluate the platform?
Test with representative workloads. Object storage, worker-local disk, and CPU and RAM are sized separately, against data volume, query scope, concurrency and refresh targets. DataWalk works through sizing with your team during deployment planning.
Next step

You are not buying a faster report. You are buying the questions you can’t ask today.

The architecture you choose determines how far you can explore, how much engineering it takes to get there, and how easily you can adapt when requirements change. Put DataWalk to the test with your data, your workloads and your infrastructure. Find out what’s possible without the usual limits on scale, complexity and change.

Discuss your deployment requirements

Evaluation brief

  1. 01Data size and growth
  2. 02Relationship volume and depth
  3. 03Representative analytical queries
  4. 04Expected concurrency
  5. 05Ingestion and refresh targets
  6. 06Target environment: cloud, on-premises or air-gapped
  7. 07Kubernetes platform and version
  8. 08Object storage and container registry
  9. 09Team operating the deployment
  10. 10Identity, access and recovery requirements