Hi @MoFabricIoT
I understand you're planning to send several smaller JSON payloads instead of one big one, each with a subset of sensors from the same device, and you want to know if Fabric handles that well.
Before going into detail, one question: is the final destination a KQL Database or a Lakehouse? Eventstream can do both. The input arrives as JSON and inside Eventstream itself you configure the destination, either a table in a KQL Database (Eventhouse) or a Delta table in a Lakehouse, and in both cases the mapping to typed columns is handled by the destination wizard. Reference docs:
https://learn.microsoft.com/fabric/real-time-intelligence/event-streams/add-destination-kql-databasehttps://learn.microsoft.com/fabric/real-time-intelligence/event-streams/add-destination-lakehouse
That said, my opinion on your approach: splitting the payload into smaller JSON messages is a perfectly valid solution and it doesn't cause any issue for Eventstream. It natively supports individual JSON objects, nested JSON, arrays and NDJSON, so you can generate multiple JSONs per device dynamically without trouble:
https://learn.microsoft.com/fabric/real-time-intelligence/event-streams/data-formats
Two recommendations that will save you work later:
1.Include a common identifier in every JSON, such as device_id, capture timestamp and sensor_type. That way you can correlate in a single query all the messages coming from the same device even if they arrive separately.
2.If the different sensor types have very different fields, you have two clean approaches: a single table with the union of all possible fields (the ones not present in a given message will be null), or multiple destination tables using derived streams filtered by sensor_type. The first one is simpler, the second one tidier if the schemas diverge a lot or you want different retention policies per sensor type.
If this helped, please consider giving it a Like. If it solved your issue, please mark it as the Accepted Solution to help others facing the same problem.
Thanks
