Weighing storage-in-place against a linked shortcut for a Real-Time Intelligence table

In Real-Time Intelligence, you choose between ingesting data into native Eventhouse (KQL database) tables or creating OneLake shortcuts to data that already exists elsewhere in OneLake. Native tables give you full KQL engine performance and streaming capabilities, while shortcuts let you query existing data in place without duplicating storage. The right choice depends on whether you need high-performance time-series analytics/streaming or just want to avoid copying data that already lives in a Lakehouse or Warehouse.

1 · Learn the must-know

• 1Native KQL database tables use columnar storage with built-in indexing (e.g., term, range indexes), enabling fast ad-hoc and time-series queries not achievable on shortcut data.
• 2Native tables support streaming ingestion, update policies, and materialized views, features that are not available on shortcut-referenced data.
• 3OneLake shortcuts are read-only virtual pointers to data stored in OneLake (or external sources like ADLS/S3) that avoid data duplication and let KQL queries reference Delta/Parquet data in place.
• 4Use shortcuts when the source data already resides in a Lakehouse or Warehouse and you want to query it from Real-Time Intelligence without an extra copy or ETL step.
• 5Querying shortcut data is generally slower than querying native tables because it lacks the Eventhouse-specific indexing and caching optimizations.
• 6Use native tables when you need low-latency streaming ingestion, retention policies, or advanced time-series functions that require the full KQL engine capabilities.

2 · Check your understanding