Confluent’s November 6, 2026 release notes list Lightning Tables as generally available in Confluent Cloud on AWS. A Lightning Table exposes Kafka topic data to read-only SQL queries. Confluent documents an upsert mode that keeps the latest state for each key. That makes the key a useful first thing to check in a pilot.
Try two updates and a second record
Imagine a fictional shipment tracker. Send a test record for shipment A with status packed, then update that same key to shipped. Send a third record for shipment B with status packed. In a current-state view, you expect two shipment rows: A shipped and B packed. In an event history, you would still want to see all three changes.
A test that returns two rows can still miss a problem. Compare the actual keys and statuses with the expected ones. If your producer accidentally uses the warehouse ID as the key, two shipments at the same warehouse could be treated as one current record.
Check the view your app will actually use
- Write down whether the app needs current state, event history or both.
- Check the key on several records, including two records that share a customer or location but should remain separate.
- Measure the time between a test update and when your query first returns the expected state. Record the test conditions beside the result.
Use fictional data and a read-only test query. A successful sample shows what happened for those keys and conditions. It does not establish how every producer or workload will behave.