What Is RunReveal?

The Problem Nobody Loves Admitting

Every SOC analyst I know has a version of the same complaint.

• Splunk gets expensive the moment your log volume grows past whatever number your finance team quietly panicked about last renewal.

• Sentinel is great if your entire estate lives in Azure and painful the moment it doesn't. And half the SIEMs on the market still feel like they were built for a world where a 'query' meant clicking through six dropdown menus instead of just writing SQL.

RunReveal showed up on my radar because it skips a lot of that. It's a security data platform built directly on ClickHouse, which is the same database engine a lot of observability companies quietly switched to once they got tired of Elasticsearch falling over at scale. I spent the last few weeks actually building against it — not reading a datasheet, but standing up sources, writing detections, breaking things, and building a small MCP server so I could query it from inside AI agent. This series is what I found.

A note on how this series was written: Every technical detail in this series — endpoint behavior, schema fields, quirks, things that are flat-out broken right now — comes from hands-on testing against a real RunReveal workspace, not from marketing copy. Where something is broken, I say so.

So What Is It, Actually

RunReveal calls itself a modern security data platform, and for once the adjective is doing real work instead of just filling space.

The pitch is:

Detection-as-code instead of point-and-click rule builders, AI-powered investigation triage instead of an analyst opening forty browser tabs, and sub-second query performance because the whole thing sits on a columnar database instead of a traditional log indexer.

Strip away the marketing language and here's the actual shape of the thing:

• Sources pull data in — cloud providers, identity platforms, EDR tools, SaaS apps, roughly 120 connectors and counting.

• Pipelines and Topics move that data around and let you transform, enrich, or filter it before it lands anywhere.

• Everything ends up in one big ClickHouse table, which detections (written in SQL or Sigma) query on a schedule.

• A match escalates through detections → signals → alerts, getting louder each step, until it hits a notification channel.

• Alerts spin up Investigations — timeline-based case objects with their own AI triage agent.

That pipeline — source to signal to investigation — is the spine of this whole series. Every later article is really just zooming into one link of that chain.

Who This Is Actually For

I don't think RunReveal is trying to be Splunk's replacement for a 500-analyst enterprise SOC that already has a decade of SPL knowledge baked into its team. Where it makes sense, at least from what I've seen, is smaller or leaner security teams who are comfortable with SQL, don't want to pay an ingest tax on every gigabyte, and want their detections to live in version control instead of a vendor's proprietary rule editor.

It also clearly leans into being AI-native rather than having AI bolted on as a chatbot sidebar. The investigation triage agent, the native AI chat, and the fact that it exposes an MCP server so tools like Claude can query your workspace directly — that's a different design philosophy than most of the incumbents, who added "AI" to their SIEM after the fact.

The Eight Pieces That Make Up the Platform

Here's the map I wish I'd had on day one:

• Sources — where data comes from.

• Pipelines & Topics — how data moves and gets shaped in transit.

• Detections — SQL or Sigma rules that scan the data on a schedule.

• Signals & Alerts — the escalation ladder from "something matched" to "someone got notified."

• Investigations — the case file, with an AI agent doing first-pass triage.

• Search / Explorer — ad hoc querying against the same ClickHouse backend.

• AI Chat — a native, in-console, fully-audited conversational interface over your data.

• Dashboards — the usual visual rollups, built on top of everything above.

None of these are novel concepts on their own — every SIEM has some version of sources, detections, and alerts.

What's different is how thin the layers are between them.

There's no separate indexing tier, no proprietary storage format you need a support ticket to query around. It's one table, underneath everything.

What's Coming in This Series

This is the first of twelve articles.

The next one goes under the hood of the ClickHouse architecture itself — the actual table schema, how pipelines route data, and a genuinely interesting design decision about where the "real" write to storage happens.

After that: the Explorer and how you actually query all of this yourself, everything that can happen to an event in flight before it's ever stored (transform, filter, drop, mask, sample, enrich), ingestion and the connector catalog, the detection engine, investigations and AI triage, scheduled AI agents (including a live gotcha I hit building one), notifications, the AI Chat and MCP integration (including the MCP server I built), a head-to-head comparison against Splunk and Microsoft Sentinel, and finally a full hands-on build of a detection pipeline from scratch, screenshots included.

If you're the kind of person who reads a SIEM's docs page and immediately wants to know what actually happens when you hit the API instead of the marketing site — you're going to enjoy this series more than most.

---------------------------------------Dean------------------------------------------------------