[ellisv]

The README would benefit from a comparison to other tools.

I’m not (necessarily) motivated to switch tooling because of the language it is written in. I’m motivated to switch tooling if it has better ergonomics, performance, or features.

[karakanb]

good point, thanks. I'll definitely add some more details about the comparison between different tools.

I agree with you 100% on the language part, I think it is an interesting detail for a data tool to be built in Go, but we have a lot more than that, a couple of things we do there is:

- everything is local-first: native Python support, local VS Code extension, isolated local environments, etc

- very quick iteration speed: rendered queries, backfills, all running locally

- support for data ingestion, transformation, and quality, without leaving the framework, while also having the ability to extend it with Python

these are some of the improvements we focused on bringing into the workflows, I hope this explains our thinking a bit more.

[ellisv]

My #1 feedback would be to expand on the documentation.

I really want to know how this is going to benefit me before I start putting in a lot of effort to switch to using it. That means I need to see why it is better than ${EXISTING_TOOL}.

I also need to know that it is actually compatible with my existing data pipeline. For example, we have many single tenant databases that are replicated to a central warehouse. During replication, we have to attach source information to the records to distinguish them and for RBAC. It looks like I can do this with Bruin but the documentation doesn't explicitly talk about single tenant vs multi-tenant design.

[karakanb]

I would love to add a dedicated section on this, and would love to learn a bit more from you in this. Do you have any particular example tools that you would compare Bruin in your mind that you would like to understand the difference better?