We moved from the SQLGlot-based parser to our own Go SQL parser and made Bruin binaries 30% smaller + 75x faster on a fresh install. Ours was a bit of a peculiar usecase for sqlglot: Bruin CLI is written in Go, and sqlgot is in Python. This meant that we had to find a way to embed sqlglot into our Go process somehow without requiring our users to install stuff. The solution we found to that was go-embed-python by @codablock. It runs Python in a separate process using the standalone builds maintained by @astral_sh folks, and enables communication between Go and Python processes via stdin/stdout. This solution allowed us to embed sqlglot into Bruin CLI for ~2 years. While this worked well, it had a few shortcomings, mostly around startup performance, build process complexity, and type safety between the processes. It worked fine enough, and we didn't prioritize eliminating this up to now. I don't think it was the case that sqlglot itself is slow, it is just that the way we wired it made it slower than it could have been by nature. We parse queries in a lot of commands in a one-off fashion, which meant that we had to pay the Python import costs in every import. For a while I experimented with the polyglot library, Rust-based SQL parser, to eliminate the Python dependency in general. While the library seems to have worked nicely, the slowness of the build process made many of our agentic development activities slower and more expensive, and I ended up stopping that experiment after a few months. Having a SQL parser in pure Go was a long-standing side project of mine, but the ROI to do that wasn't there. While messing with a feature last week, I thought: why not just throw this to an agent and see if we can have one in Go? In about 3 prompts, we had a 100% compatible -for our use cases- SQL parser in Go that did everything sqlglot did for us. Faster, easier to compile and distribute, and virtually zero startup time. It is a direct port of sqlglot to Go, it just rewrote the existing Python code in Go, along with references to the original Python codebase, and made sure the tests passed. I included the original sqlglot license in the package as well/ This is not a shade to sqlglot; on the contrary, I think it is a lovely piece of software, and sets the standard on quality for parsing complex SQL. It just wasn't the right fit for what we were doing, parsing SQL from a Go process. We had to pay the Python overhead and lost quite a bit of the DX benefits of Go. We had to bundle a full Python build into our binary, and start a fresh process every time we had to parse queries. Our customers run Bruin CLI on a variety of machines, and the speed impact of this on an overloaded Windows machine is even bigger. The credit belongs to @Captaintobs and his team for building and maintaining an awesome library that served us well for such a long time. I have full respect for them. On the other hand, this experiment is both exciting and scary for the future of software development. It took me ~15 mins to generate a specialized version of a dependency we had, which dramatically changes the nature of what I would consider depending on in general. The same applies to the software we build as well: if people can generate complete systems in a short amount of time, what is there to build for the long run? As I said, both exciting and scary.

We built a reverse ETL product into ingestr. You can replicate data from any source to any destination with a single command. Fully open-source We built ingestr to be a flexible enough layer to solve any data transportation usecase, and reverse ETL is one of them. You enrich some data inside your Snowflake warehouse, and you sync this data back to Salesforce with a single command. This is all open-source, and built on the same core principle: a single command to move data from anywhere to anywhere. I am glad to see the premise realized with the launch of reverse ETL. With this, Bruin becomes the only platform, and the only open-source tool with built-in ingestion, transformation, quality, governance, BI, and reverse ETL. I'd love to hear your thoughts on how we can make this better.