How we built a 43-connector CMDB with LLM pattern-learning discovery

Repo: https://github.com/Happy-Technologies-LLC/configbuddy A few years back, I was working on infrastructure where nobody trusted the CMDB. The data was perpetually stale. Connectors broke after every API update. Nobody used it for decisions — it was a ritual: we had a CMDB because enterprises have CMDBs. This post is about what I built to solve that problem, why I made the architectural choices I made, and what I'd do differently if I started over. The project is called ConfigBuddy. It's now open-source under Apache 2.0, and I'm writing this less as an announcement and more as an architecture deep-dive for other people working on infrastructure tooling. Skip to the parts you care about: The problem with traditional CMDB discovery Why Neo4j over PostgreSQL for the primary store The connector split: 17 TypeScript + 26 JSON Pattern-learning discovery: discover once, replay forever The identity resolution problem nobody talks about Unified credentials with protocol affinity The enrichmen