As of today this remains too much to save a few bucks. I’ve found a better use of duckdb in sqlmesh is to leverage it for fast local development, but leave production work to your main engine.
Yes, indeed, the additional engineering work quickly outweighs the credit savings you can achieve. However, I believe that with better tooling, this may not be the case in the future.
Very good article! It is always good to discover new ways of processing data, especially with trending technologies like DuckDB and SQLMesh. Congratulations guys!
Great writeup and nice to see a real life example. Highlights all the warts and limitations though vs the all in one solutions that you get from going all in on one stack. Excited to see these get resolved though.
I am seeing this a lot - great feedback
As of today this remains too much to save a few bucks. I’ve found a better use of duckdb in sqlmesh is to leverage it for fast local development, but leave production work to your main engine.
Yes, indeed, the additional engineering work quickly outweighs the credit savings you can achieve. However, I believe that with better tooling, this may not be the case in the future.
Very good article! It is always good to discover new ways of processing data, especially with trending technologies like DuckDB and SQLMesh. Congratulations guys!
Thanks Bruno !
Great writeup and nice to see a real life example. Highlights all the warts and limitations though vs the all in one solutions that you get from going all in on one stack. Excited to see these get resolved though.
Yes, it’s a great area of innovation for data entrepreneurs! 😊
thanks for pointing out, will check