Our Splunk bill was a crime against finance. We were pushing ~200GB/day of log data, and the "cost per GB" game was killing us. The final straw was watching queries on a 30-day window spin for minutes. We pulled the trigger on Panther six months ago. Here's the raw report.
**The Setup & Migration**
We're a Snowflake shop, so Panther's native Snowflake integration was the main draw. The pipeline pattern is now:
1. **Ingest:** Raw JSON logs land in an S3 staging bucket via FluentBit.
2. **Load:** Panther's S3 Snowflake auto-ingest pipes them into a `PANTHER_LOGDB.RAW_LOGS` staging table.
3. **Transform:** We use dbt in Panther to parse, structure, and enrich. Critical step: early filtering of noise.
```sql
-- Example dbt model to filter and parse early
{{ config(materialized='table') }}
SELECT
p_log_source,
p_event_time,
PARSE_JSON(raw_data):user_id::STRING as user_id,
PARSE_JSON(raw_data):event_type::STRING as event_type
FROM {{ source('panther', 'raw_logs') }}
WHERE event_type IN ('auth_failure', 'auth_success', 'file_delete')
-- Filter 70% of noise here
```
4. **Detect:** Panther's rules run on the transformed, filtered dataset in Snowflake. This is key—you run rules on structured data, not raw text.
**Cost Breakdown**
* **Splunk (old):** ~$45k/month. Opaque, based on license and workload.
* **Panther (now):** ~$12k/month. Breakdown is clear:
* Panther SaaS fee: ~$4k
* Snowflake compute (for queries/rule runs): ~$5k
* S3 storage & transfer: ~$3k
We saved roughly **75%**. Biggest win was decoupling storage from compute. We keep 90 days hot in Snowflake, the rest goes into cheap S3/Glacier. Querying cold data is slower but at least it's *possible* without a sales call.
**Speed & Performance**
* **Rule Execution:** Most scheduled rules complete in under 2 minutes vs. Splunk's 5-10 minute "search" window. We parallelize them heavily.
* **Ad-Hoc Investigations:** Querying structured data in Snowflake with proper clustering keys is night and day. A 24-hour window across all data takes ~10 seconds.
* **The Catch:** Latency. The Panther-on-Snowflake model is not real-time. Expect 2-5 minutes from log event to alert. If you need sub-60 second detection, this isn't the right architecture.
**Battle-Tested Patterns We Learned**
* **Aggregate Early:** Don't run rules on raw streams. Build summary tables (e.g., failed logins per user last hour) and run rules on those.
* **Tag Your Data:** Use Panther's log source tagging religiously. It makes rule targeting and cost attribution sane.
* **Tune Snowflake:** This is 80% of your performance. Use task clusters, right-sized warehouses, and monitor the query profile.
**Pitfalls**
* The initial learning curve is steep if you're not solid with SQL and dbt.
* You own the pipeline reliability more than with Splunk. Monitor your Snowflake tasks.
* Complex regex parsing is slower. Push it to the dbt transformation layer, not the rule.
Bottom line: If you have a competent data engineering team and are drowning in Splunk costs, Panther on Snowflake is a viable, cheaper, and more powerful alternative—if you can tolerate minor latency.
garbage in, garbage out