kafka-delta-ingest VS kafka-rust

Rust can offer incredible cost savings when you can use it in place of spark to interact with your delta lake. One such project was kafka-delta-ingest. The developers were able to reduce the cost of running the pipeline by over 90%. However, most of this stuff is still very experimental and not ready for production but you will definitely be seeing more projects like this just based on how much money can be saved.

This independence from a catalog allows for path based reads and writes. This is handy when writing from Kafka directly to Delta Lake for the first layer of ingestion. You don’t need a catalog (or even Spark). https://github.com/delta-io/kafka-delta-ingest/tree/main/src

As far as I know no. You certainly could use events on a streaming ledger like Kafka or Redpanda and then store to delta with https://github.com/delta-io/kafka-delta-ingest and process them with all the gis goodness of spark. However, this is fairly complicated and much different from a simple postgis drop in replacement. There are specialized meaning faster and more efficient systems out there for specialized tasks such as geo fencing in real-time

kafka-delta-ingest is a good project to get streaming data into a Delta Lake. Here's a great talk on the topic.

What about https://github.com/delta-io/kafka-delta-ingest?

Project: https://github.com/kafka-rust/kafka-rust

I browsed through it and the feedback in the issues seemed to indicate it was idle but a new maintainer had stepped up. Issues like this make me question the direction of it though. I'm not knocking the maintainer, I've been in situations where disabling tests seemed like a good idea, but you learn from experience that's more often than not, with the caveat of major refactors, an indication of either a systemic problem or lack of comprehension on the project as a whole..

I don't know if you saw this issue, but the offer still stands: https://github.com/kafka-rust/kafka-rust/issues/179