Today engineers spend dozens of hours agonizing over how to unlock the vast analytical possibilities of JSON data in their warehouse. The internet is littered with half solutions and broken promises. Today, we have solved this problem.
Hi HN, I’m Brady. I’ve spent years watching data engineers burn out writing brittle parsers for nested JSON, only to have dashboards crash because an upstream API changed a field name.
I built Forge to solve this. It’s an autonomous data infrastructure platform that ingests raw, nested JSON and automatically generates production-ready dbt models.
The Problem Traditional ETL tools (Fivetran/Stitch) often dump raw JSON into a VARIANT or string column, leaving you to write complex parsing logic manually. This is expensive to query and hard to govern. If the schema changes, your SQL breaks.
What Forge Does Forge parses your JSON and compiles it into optimized, native tables for BigQuery, Snowflake, Databricks, and Redshift.
Deep Unnesting: It flattens arrays and objects 5+ levels deep into relational tables with proper keys.
AI Classification (Excalibur): We use a Graph Neural Network (GraphSAGE) to classify data patterns (e.g., identifying "customer" vs. "inventory" data) without the data leaving your environment.
Auto-Governance (Pridwen): It detects PII and automatically applies hashing or masking policies based on the classification.
Multi-Warehouse Support: One JSON source generates native SQL for all supported warehouses simultaneously.
How it works Under the hood, Forge generates a full dbt project. You get the exact SQL code it generates, complete with lineage and documentation. We focused heavily on transparency—no black boxes.
Where we're going We are currently working on Llamrei (Q2 2026), which will handle schema evolution by automatically normalizing legacy API versions into "golden schemas" to prevent breaking changes.
We have a free tier (no credit card required) that lets you run full jobs to test the output.
I’d love to hear your feedback on the generated SQL structure and our approach to using GNNs for schema inference.