Google's acquisition of Wiz for $32 billion was a clear signal to the industry: the cloud security war has a winner. What’s more interesting is how they won. Wiz wasn’t the first mover. Lacework started five years earlier with a solid team, strong product vision, and top-tier VC backing. So what went wrong for Lacework? And what went right for Wiz?

If you browse social media, you’ll find engineers and CISOs asking the same thing. Threads on X, Reddit, and Hacker News have dozens of posts dissecting the matchup. The answer holds lessons not just for security vendors, but for anyone building modern data-intensive products.

Obviously, Wiz did many things right from product strategy and GTM to customer support and execution. But there’s one angle I haven’t seen talked about much in the usual analysis. It happens to be my niche: data infrastructure. It might just be their secret weapon, and that’s what prompted me to write this breakdown.

Take Reddit, for example. Multiple posts are comparing Lacework and Wiz, with engineers sharing firsthand experiences from evaluations and deployments.

I’m not a security guy. I come from a data infrastructure background. But this story is just as much about data architecture as it is about product strategy.

Let’s look at what each company built.

Lacework: Graph Ideas, SQL Reality

Lacework launched in 2015 with the Polygraph® Data Platform. It aimed to detect threats by mapping relationships and behaviors between cloud assets, a classic graph use case. But under the hood, Lacework didn’t use a graph database. They built it on Snowflake.

Why Snowflake? Probably because Sutter Hill Ventures incubated both companies. And to be fair, Snowflake made sense on paper. It offers strong scalability and relatively low cost. You can store huge volumes of cloud telemetry, and it scales elastically. That’s helpful for cost control and data retention.

But there’s a catch. Snowflake isn’t built for graph workloads. Writing a 3-hop relationship query in SQL can take 100+ lines of nested joins. Here’s what a basic traversal looks like in SQL:

SELECT a.user_id, d.device_id, n.network_id
FROM users a
JOIN logins b ON a.user_id = b.user_id
JOIN devices d ON b.device_id = d.device_id
JOIN connections c ON d.device_id = c.device_id
JOIN networks n ON c.network_id = n.network_id
WHERE n.public = true;

Now imagine debugging this at 10 hops, with filters, aggregations, and alert logic. Even the best engineers will slow down. Development becomes brittle and difficult to maintain.

Wiz: Native Graph, Feature Velocity

Wiz was founded in 2020 by Assaf Rappaport and his former team from Adallom. They chose a different path. From day one, Wiz used Amazon Neptune, a native graph database.

In a joint blog post with AWS titled "The World is a Graph", Wiz CTO Ami Luttwak explained their approach:

"The world is a graph, not a table. It’s time our tooling reflected this."

Wiz modeled everything, users, assets, roles, and flows, as nodes and edges. They queried it with Gremlin. Here's a real-world example:

g.V().hasLabel("vm").has("public", true)
  .out("connectedTo").hasLabel("network")
  .out("reachableBy").has("role", "admin")
  .path()

This kind of logic is expressible in 10 lines with Gremlin. In SQL? It would be a nightmare.

This architectural choice gave Wiz a massive edge in developer velocity. With Neptune and Gremlin, engineers could express complex security logic in concise, readable queries and ship them quickly. What would take days or weeks in SQL due to brittle joins and long query chains could be prototyped and pushed in hours. This mattered. Security is a fast-moving field, and Wiz’s ability to ship features at startup speed meant it could respond to customer requests, compliance requirements, and threat intelligence faster than Lacework. Even with a smaller team, they consistently outpaced Lacework’s product delivery cadence.

By 2022, Wiz deepened its commitment to graph infrastructure by continuing to scale on Amazon Neptune. Their bet on native graph tech was not just architectural; it defined their velocity and differentiation.

The Graph Bet That Changed Everything

Lacework prioritized cost efficiency. By using Snowflake, they could ingest and retain massive volumes of telemetry with elastic scaling and lower marginal cost. They didn’t need to maintain a separate graph database or optimize for graph workloads. The tradeoff was in capability: Snowflake’s tabular design wasn’t built for deep relationship queries. Modeling graph logic in SQL, especially multi-hop joins, was verbose, fragile, and hard to iterate on. This slowed down development and made advanced threat modeling harder to execute.

Wiz is optimized for speed. By betting on a native graph engine, they gained fast iteration, concise query logic, and a security model grounded in relationships. They could express new detections or traversal-based insights in a few lines of Gremlin, prototype ideas quickly, and ship updates faster.

In cybersecurity, speed wins. Customers care more about feature velocity and detection quality than marginal compute savings. Wiz took a costly but strategic path: they paid much more for infrastructure but delivered faster innovation and outpaced the field.

Lacework’s architecture helped them scale cheaply, but that same architecture made it difficult to build graph-native security features. Their bet is optimized for storage and cost. Wiz’s bet is optimized for iteration and product value. The outcome was clear.

Can You Get the Wiz Speed With Low Cost and Unlimited Scalability of Data Lakes?

If you’ve made it this far, you might be wondering: Is it possible to get the benefits of a native graph system, fast iteration, expressive multi-hop queries, without the painful cost and complexity of traditional graph databases?

Plenty of cybersecurity unicorns have attempted creative workarounds to address the scalability and cost challenges of traditional graph databases:

• A friend at a Series F cybersecurity startup told me they only store a single day’s worth of graph data, because the graph database cannot scale out.
• Another company splits its graph workload: topology stays in a graph database, but all attributes are offloaded to a warehouse like Snowflake or Databricks.

These are clever tradeoffs. But they’re still compromises.

What if you didn’t have to choose between fast iteration and low cost?

(Trigger warning: Shameless plug coming)

That’s the question we asked ourselves when building PuppyGraph, a graph query engine designed to run directly on your data lake.

• No ETL
• No duplicated storage
• Query your Parquet files or iceberg/delta tables with Cypher or Gremlin
• Subsecond response times
• Lower cost than Snowflake

Wiz chose graphs and shipped features fast. Lacework chose SQL and struggled with velocity.

The best part of the Wiz story isn’t just that they chose graphs, it’s that they embraced the tradeoff. They paid more in infrastructure, but got faster iteration and better product velocity in return.

Now imagine building at that speed, with a much smaller bill. If you’re building the next Wiz, maybe you don’t need a $32B exit. Perhaps you just need the right graph engine. (Okay fine, a $32B exit would be nice too.)