JupiterOne Accelerates Cyber Asset Security with Neo4j Graph Intelligence Platform

Most organizations still struggle to see the hidden paths an attacker might take through their digital environment. One all-too-familiar scenario: a compromised laptop connects to a developer identity, which holds a policy granting access to an S3 bucket containing sensitive customer data. In a spreadsheet, these are three separate rows. In reality, they form an attack path.

JupiterOne was built to reveal these connections. As a Cyber Asset Attack Surface Management (CAASM) platform, it ingests data from hundreds of security and IT systems — AWS, Okta, GitHub, SentinelOne — and normalizes it into a single, queryable knowledge base.

As JupiterOne scaled to unicorn status and customer data volumes grew exponentially, the team recognized an opportunity to fundamentally rethink their data architecture. What had worked well in the early startup days needed to evolve to meet enterprise-scale demands.

“We reached a point where we were spending more time managing infrastructure than building product,” says James Mountifield, Senior Director of Engineering at JupiterOne. “We saw an opportunity to simplify our architecture and unlock capabilities that would have been difficult to achieve otherwise.”

Above: JupiterOne gives users the ability to view assets, context, and risks in one place

The Case for Architectural Evolution

JupiterOne’s original architecture was designed for speed-to-market—the right choice for an early-stage startup which could buy managed cloud infrastructure and focus on application logic. But as customer needs grew more sophisticated, the team found themselves building increasing complexity into their data pipeline. As customer data volumes exploded, the underlying database mechanics could not keep pace.

To achieve the performance their customers needed, the team had implemented a dual-storage approach: one system optimized for flat queries (basic list-style lookups) and another for complex relationship traversals. While this solved immediate performance needs, it introduced synchronization challenges and operational overhead. This complex and fragile architecture created a vicious cycle. To protect the fragile database layer, JupiterOne had to manage customer activity carefully. They limited how much data customers could ingest and how often they could query it. 

“We had built a lot of custom logic to keep these systems in sync. We had this whole category of bugs that would come in when those two systems got out of sync,” Mountifield explains. “When you’re managing that kind of complexity, you spend more time debugging complaints and reconciling databases, and less time on features that differentiate you in the market.”

The team also faced the challenge common to high-growth companies: their cost structure didn’t scale linearly with value delivered. Infrastructure costs were growing faster than revenue, putting pressure on unit economics.

“Customers have paid to have this data in the system,” Mountifield says. “We wanted to remove any barriers to them getting maximum value from it. That meant rethinking our architecture from the ground up.”

The Evaluation: Finding the Right Foundation

In late 2023, JupiterOne launched a discovery project to evaluate next-generation data platforms. The team assessed three categories of solutions: pure graph databases, hybrid document-graph stores, and architectures that separate graph structure from data storage.

The hybrid approach failed quickly. The team could not even load their massive datasets during the proof-of-concept phase. Neo4j, on the other hand, proved its worth before a contract was even signed. Neo4j distinguished itself early in the evaluation through its combination of performance, operational simplicity, and developer experience.

“We managed to take our production-scale datasets and had Neo4j running in Docker on people’s MacBooks,” says Mountifield. “We didn’t have to work with sales engineers to make fixes to the product to get it in. We self-serviced. We got hold of the technology, we loaded the data, and it was working.”

This autonomy was decisive. JupiterOne needed a platform they could own, operate, and iterate on rapidly—one that would scale with their ambitions rather than constrain them.

The Migration: Hot-Swapping at Scale

Migrating a live database with hundreds of millions of nodes and billions of relationships is akin to replacing a jet engine mid-flight, requiring surgical precision. JupiterOne executed the transition in under six months using a shadow-running strategy, operating the new Neo4j clusters in parallel with the legacy system.

Writes were streamed to both systems. Reads were executed against both, with a background process comparing results to ensure accuracy.

“We could swap from serving results from the old system to serving results from the new system mid-query,” Mountifield says. “We hot-swapped customers in the middle of the working day. We had great observability in place, so if we could see it going wrong, we could instantly start serving the legacy system again.”

This approach eliminated the all-at-once migration risk typical of database cutovers. By July 2024, the legacy systems were fully decommissioned. The complex web of loops, synchronizations, and duplicate stores was replaced by a linear pipeline: data comes in, hits the graph, and is queried.

Impact: From Hours to Seconds

The results were immediate and quantifiable. Consolidating onto a single Neo4j backend not only simplified the architecture but also drove massive performance gains.

1. Speed of Insight

Under the previous architecture, data ingestion lag could reach eight hours. A security team might patch a vulnerability in the morning but not see that change reflected in JupiterOne until the afternoon.

“We’ve got that down to ~10 seconds on average now,” Mountifield notes. “For security teams, that’s the difference between reactive and proactive defense.”

2. Query Performance

For customers, the lag time for complex queries evaporated. “Our P99 latency dropped by two orders of magnitude,” says Mountifield. “Customers went from waiting up to tens of minutes for queries to our average query time going down to 180 milliseconds.”

3. Cost Efficiency

The financial impact validated the board’s decision to approve the replatforming. The cost of the data pipeline, the infrastructure responsible for moving data into the graph, dropped by more than 90 percent. “Our cloud provider bill went down substantially,” Mountifield confirms. “The project was a very valuable thing to have done.”

Opening New Security Capabilities

Beyond performance and cost, the new architecture enabled product capabilities that weren’t previously feasible at scale.

One example is JupiterOne’s external threat analysis module. It traces routes from an internal asset all the way out to the public internet, identifying exposure paths across multiple hops—without knowing in advance how many relationship traversals will be required.

Above: JupiterOne enables continuous real-time discovery and monitoring an attack surface for assets, vulnerabilities, misconfigurations, and other risks.

“That kind of dynamic, multi-hop traversal is exactly what graph databases are designed for,” Mountifield explains. “We can now offer capabilities that genuinely differentiate us in the market.”

The team also implemented bipartite graph matching to infer relationships between disparate data points, enabled Change Data Capture (CDC) streams with minimal configuration, and delivered features like regex search support in days rather than months.

Most importantly, JupiterOne removed artificial constraints on customer usage. “We can now tell our customers: query as much data as you want. Bring as much data as you think is valuable. The platform scales with you.”

The AI-Ready Foundation

With a high-performance knowledge graph in place, JupiterOne is positioning itself at the forefront of the generative AI shift in security. The company is developing “Ask J1,” a natural language interface that allows users to ask questions like “Which production assets are accessible from the internet?” and receive not just a list, but an explanation of the relationships.

“The best thing about LLMs is their ability to explain to the user what they’re looking at,” Mountifield says. “We’re getting the system to explain what the query has done and what the results actually mean. That’s proving to be incredibly powerful.”

Because JupiterOne enforces a strict ontology on data ingestion, the graph provides a grounded, deterministic foundation for AI models. This prevents hallucinations and ensures that when an AI agent describes an attack path, that path actually exists in the graph.

A Transformed Engineering Culture

The re-architecture project delivered benefits beyond technology. It unified the engineering organization around a shared mission.

“This project brought everyone together,” Mountifield reflects. “The collaboration required to pull this off made us a stronger, more cohesive team.”

JupiterOne is now exploring how Neo4j can further enable AI-driven insights, helping security teams proactively identify and mitigate threats before they materialize.

“We’re only scratching the surface of what’s possible with graph technology and AI working together,” Mountifield says.

---

JupiterOne provides the leading Cyber Asset Attack Surface Management platform, helping enterprises discover, manage, and secure their entire digital infrastructure.