Hey HN - Zingle came out of a pretty painful reality we kept seeing across data teams. We were reviewing ~60 dbt/SQL PRs a week for a client, and the senior engineers were overloaded while analysts weren’t allowed to merge anything risky. The combination of fast-moving code and slow reviews led to mistakes. The worst one on our side was a PR that triggered repeated full refreshes on a big model and blew up into a $50k Snowflake bill.
That’s when we realized we needed a reviewer that understands data behavior, not just code.
We don’t store SQL, data, metadata, or logs. Nothing leaves the customer’s warehouse.
Would love any feedback - especially edge cases that are tricky or places where our reviewer’s judgment feels wrong or incomplete. Happy to answer any technical questions.
This is cool. We had a similar issue with dbt exploding refresh costs. Curious how you estimate warehouse cost on a PR? Static analysis or do you simulate?
We mix static analysis on pre-tagged workloads with a small, safe simulation inside the customer’s warehouse. It’s been surprisingly accurate for cost impact, and we avoid triggering any heavy runs.
Hey HN - Zingle came out of a pretty painful reality we kept seeing across data teams. We were reviewing ~60 dbt/SQL PRs a week for a client, and the senior engineers were overloaded while analysts weren’t allowed to merge anything risky. The combination of fast-moving code and slow reviews led to mistakes. The worst one on our side was a PR that triggered repeated full refreshes on a big model and blew up into a $50k Snowflake bill. That’s when we realized we needed a reviewer that understands data behavior, not just code.
How Zingle works (technical outline): - SQL parser → identifies patterns, predicates, merge logic, join risks - Lineage graph engine → traces downstream models + dashboards - Warehouse metadata fetcher → table sizes, clustering, stats, partitions - Cost estimation engine → predicts warehouse impact (bytes scanned, compute, I/O) - Try re-creating affected downstream systems → safely runs new logic to analyse data diffs - Rules engine → custom governance checks (merge key, tests, docs, ownership)
We don’t store SQL, data, metadata, or logs. Nothing leaves the customer’s warehouse.
Would love any feedback - especially edge cases that are tricky or places where our reviewer’s judgment feels wrong or incomplete. Happy to answer any technical questions.
This is cool. We had a similar issue with dbt exploding refresh costs. Curious how you estimate warehouse cost on a PR? Static analysis or do you simulate?
We mix static analysis on pre-tagged workloads with a small, safe simulation inside the customer’s warehouse. It’s been surprisingly accurate for cost impact, and we avoid triggering any heavy runs.
Congrats! Curious why the name Zingle tho? Sounds like a dating app haha.
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]