|
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. |
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.