Q: Why did we create a STREAM of device data, and then a TABLE ? When should we use STREAM and when should we use TABLE ? A: Great question! Logically, we are using the device data as a TABLE . That is, we want to join an inbound stream of events to our device data in order to enrich it. We want to know for a given key, what the corresponding values are. For a given device row, what’s its name, it’s model, it’s version etc. So it is most definitely a TABLE . But, in order to join to a TABLE , that TABLE must be keyed on the join column. And as we saw from inspecting ROWKEY above, this was not the case. So we utilised KSQL’s powerful re-keying functionality to rekey the topic automagically. And to do that, we treat the inbound data as a STREAM . Why? Because it’s simply an inbound Kafka topic of events, partitioned on one column and on which we want to partition another. Each event (in this context, a change to the source device data on MongoDB) simply needs re-routing to the output topic with the new partitioning key.