What this case proves

This is not a slide about streaming. It is a full path you can inspect, run, and explain in an interview or architecture review. The project captures PostgreSQL changes from WAL, publishes them into Kafka through Debezium, normalizes payloads in Python, and only then promotes the data into dbt layers that analytics teams can trust.

Why the design matters

The strongest decision in this repo is transparency. Instead of hiding transformation logic inside an opaque connector, the consumer owns coercion and UPSERT behavior. That makes the data movement easier to test, easier to reason about, and easier to extend when business rules change.

Tradeoffs worth calling out

The stack is intentionally local-first. It uses Docker Compose, a target PostgreSQL, and Streamlit so the operating pattern stays visible. That is great for proof and learning, but in production you would likely add schema registry, lag monitoring, stronger secret handling, and managed scheduling.

Practical takeaway

If the business problem is stale operational analytics, this case shows a credible middle path: fresher data without pretending every company needs a heavyweight platform from day one.