This has been discussed a bit throughout the commu...
# best-practices
m
This has been discussed a bit throughout the community already, but what is the response from Meltano on this rather one-sided take from Airbyte? Did someone write up a rebuttal or a more nuanced piece comparing the two approaches? I love Meltano for its DevOps and everything-as-code style, as well as the ease of setup and flexibility, as well as the nice integration with pretty much any orchestrator and even dbt (which also uses the same approach as Meltano).
I would be particularly interested in the fundamental difference in Singer vs monorepo, as well as the reverse-ELT functionality that is supposed to come out of Airbyte buying Grouparoo).
Any good writeups out there?
s
Good question, none that I know of. I remember this one article which echoes your comments about meltano but obviously would love another one which is from a more level perspective as you mention: https://gitznik.medium.com/airbyte-or-meltano-and-why-i-use-neither-of-them-4dcfcfafb86a.
m
Yeah, that's the one I found already, but it is a bit high-level and not really based on real experience with the two. For example, I hated that it says Meltano is not scaleable, because from my view Meltano focuses more on being portable - it can run on my laptop at low scale, and on k8s for "infinite" scale. I may take the time to write up some of my initial findings with Meltano, and invite some Airbyte-fans to rebuke them 😄
s
If you're up for it and got a rough draft, you can always contact me. I'd be happy to assist you.
t
I’d love for us to do a write-up on the difference between the Singer and Airbyte specs b/c the reality is they’re not that different at all. As with all things there are tradeoffs to the different approaches but we think Meltano is better 😄 Also, love this quote “I love Meltano for its DevOps and everything-as-code style, as well as the ease of setup and flexibility, as well as the nice integration with pretty much any orchestrator and even dbt”
c
I haven't really done any deep investigation into AirByte and I have never actually used it. But, with the most important component for me personally being the SDK/CDK, I am already put off by AirByte because of:
Dependencies
1. Python >= 3.9
2. Docker
3. NodeJS
.... https://docs.airbyte.com/connector-development/tutorials/cdk-speedrun#dependencies
Docker
I don't have any time to troubleshoot Docker networking just to write some ELT connectors ... 😉
a
I used airbyte and it failed epic-ly. The TL;DR I then wrote a 2 <100 line python async scripts that took a 7+ hour airbyte sync down to like 20 mins... Took me maybe 2 hours to put the scripts together vs days of troubleshooting, standing up a service on k8s, getting security approvals, testing a connector which required a service running on a machine locally, sad-face when some syncs were 7+ hours, finding that same connector validated locally failing in production when it was finally go-time (ofc a 7 hour run each failure because it hung at the end), reaching out on their slack and being rerouted to discourse, posting on discourse where replies were going out above and below my question without much curtesy, issue on github which didnt go anywhere (on my timeline at least), and much of it was out of my hands because dissecting a connector was so convoluted. Never touched it again 🙅‍♂️
They'll improve with time (probably?)... But even then I prefer Meltano for reasons stated above. Most of all flexibility, simplicity, and integration with developer workflows. I want to see meltano become almost kubernetes like in its approach to resources/config. It's not far in how it's already focused on its cli and yaml representations of config. But more pages from that book would be dope and I can see it leaning that way.