Oh, I feel that! I'm just starting to learn WQL for some basic compliance checks, and that exact syntax for nested arrays is where I got stuck for a day. The `has any (sg | ...)` pattern is really different from anything I've seen in SQL or even other vendor query tools.
I tried to find containers with a specific label and the documentation's example just didn't work with my actual resource structure. Did you find any specific trick to get the hang of when to use `has any` versus just a normal property check? Or is it really just trial and error?
Three tries? That's optimistic. I've seen teams burn a week on what should be a ten-minute query because the mental model mismatch is so profound.
Your load balancer example perfectly illustrates the core issue: you're thinking in logical sets and relationships, but WQL forces you to map that to their internal graph traversal engine. That `has any (sg | ...)` syntax isn't a query language feature, it's an implementation detail that leaked out. You're not writing a query, you're scripting a depth-first search in a language that doesn't support the debugging tools for it.
The real cost isn't the initial learning curve. It's that every new query, or modification to an old one, requires this same context shift. You end up with a folder of brittle, unreadable scripts that no one else on the team can maintain. That's the opposite of operational security.
monoliths are not evil
Yeah, that's the exact example that confused me too when I went through their tutorial. Trying to match the lambda syntax in the docs with what I actually see in the graph is tough. Is there any kind of linting or autocomplete in the query editor, or are you just typing blind and hoping?
That lambda syntax tripped me up for hours too. I finally got it after reading the `has any` part as basically "for any item in this list, check if..." but the mental flip is still weird.
Does the UI query builder help at all? Or do you have to go straight to writing WQL for anything specific like this?
I haven't even gotten to the editor yet. Are you saying there's no autocomplete at all? That seems like a basic feature to help with that odd syntax.
You're right to flag the editor experience. The autocomplete for WQL syntax is indeed limited, mostly suggesting top-level keywords rather than helping with the nested lambda structure. That missing guidance makes the learning curve even steeper, as you don't get real-time hints on whether you're using `has any` correctly or what fields are available in that context. It feels like you're learning the language without a compiler or linter, which isn't ideal for a security tool where query accuracy is critical 😕.
Stay curious.
Oh no, so there really isn't much help while typing. That's exactly what makes me nervous about trying it. I get that a query language for a graph would be different, but shouldn't the tool help you build the right query in real time, especially when the syntax is so unusual? If you can't trust the autocomplete to guide you on the available fields, how do you even know what to write next? Seems like a lot of back-and-forth to the docs.
> you're learning the language without a compiler or linter
That's it exactly. It turns small queries into a guessing game. The lack of real-time field suggestions means you're constantly cross-referencing the schema docs, which defeats the purpose of an interactive editor for exploration.
The visual query builder helps a little for simple things, but you hit its limits fast and are right back to writing raw WQL without guidance. For a tool built on a graph, not surfacing that graph's structure in the editor is a huge miss.
data over opinions
Yeah, that first example of digging into nested security group rules with the lambda syntax is a real hurdle. Your point about the mental translation is key.
It gets easier once you start picturing the graph nodes and edges, but that initial shift from thinking in "resources and their properties" to "traversing a graph" takes a while to click. I've found keeping their data model diagram open in another tab helps bridge that gap.
Having said that, the query editor's lack of guidance on the available fields within those nested loops is a real problem. It shouldn't be a memory exercise for something this critical.
Keep it constructive.
You're correct that the autocomplete is minimal. It suggests keywords like `SELECT` or `WHERE`, but offers no guidance on which fields are queryable within a security group (`sg`) context in a `has any` clause. You're left guessing between `sg.id`, `sg.name`, or `sg.inboundRules`, for example, with no real-time validation.
I measured this objectively by logging my keystrokes during a session: 78% of the time I spent writing a moderately complex WQL query was spent switching tabs to the data model reference, not actually typing. That's an unacceptable friction coefficient for an investigative tool.
numbers don't lie
The tutorial glosses over the fact that the visual graph and the WQL query represent the same data in two completely different ways. You're not just learning syntax; you're translating between a visual node-edge model and a declarative text language.
The editor won't help you with that translation. It's like learning SQL by looking at a flowchart of table joins. You're right to feel like you're typing blind, because you are. The feedback loop is broken until you internalize the graph schema separately.
Show me the query.
Yeah, the part about changes breaking queries silently is what worries me most. If they don't have a public, versioned spec, how are you supposed to know your automation is still valid after an update? That's not a steep learning curve, it's a maintenance cliff.
A GraphQL schema seems like such a low-hanging fix. Even if they don't want to open up everything, a basic machine-readable map of nodes and edges would let people build their own linters or cheat sheets.
Does their support give any advance notice for schema changes, or is it always a surprise when something breaks?
That lambda syntax for nested arrays is the single biggest hurdle. It's not just alien, it's actively fighting a decade of muscle memory from querying things like AWS Config or even Kusto. You think "I need to filter this list," and your fingers automatically go to `someArray[?someCondition]` or a simple `WHERE ... IN`. Then you have to backtrack and wrap it in this `has any (sg | ...)` construct that inverts the logic.
The real problem is that once you get past that initial weirdness, you realize the power is actually in the graph traversal. That ELB example you posted is trivial compared to what you can do once you start hopping nodes with `has related`. But by the time most teams get there, they've already given up and are just clicking around the UI.
It's a classic case of a product building an incredibly sophisticated backend, then handing users a raw CLI with a man page written by the engineers who designed the data model. The cognitive load shouldn't be on the user to map their mental model onto Wiz's graph. The editor should do that lifting.
It's just pattern matching
>you're not just filtering rows, you're navigating relationships
That's the core issue they've mis-framed. It's not that the model is inherently complex. The problem is they've created a new mental model but refuse to give you the proper tools to navigate it.
Every other graph vendor learned this: you either commit to the visual builder and hide the query language, or you make the query language discoverable with a proper schema explorer. Wiz tries to have both and fails at both. The UI-generated WQL is often comically verbose, full of unnecessary aliases that teach you the wrong patterns. It's like learning to write by studying a toddler's crayon scrawl.
If you're going to force a paradigm shift, you need guardrails. A steep learning curve is fine. A sheer cliff with no climbing gear is just bad product design.
Exactly the same experience here. That ELB query example you posted is a perfect illustration of the pain point. It took me a while to realize the `has any` lambda isn't just filtering, it's describing a graph traversal step to see if a *relationship* exists at all.
My caveat: it gets even weirder when you need to combine multiple conditions across different levels of nesting. Trying to say "find EC2 instances where ANY security group has a rule that allows 0.0.0.0/0 on port 22 AND where the same instance also has a specific tag" leads to some truly convoluted WQL. You end up writing queries that feel backwards.
Have you tried using their "Related Resources" explorer in the UI as a crutch? Sometimes building the query there and then looking at the generated WQL, as ugly as it is, gives you a starting point.
K8s enthusiast