Microsoft-Fabric

One of the really practical features of KQL databases in Microsoft Fabric is that they don’t lock you into a single query language. While KQL, or Kusto Query Language, is the native language of these databases, you can also query them using standard SQL syntax, including T-SQL style statements that most data professionals are already comfortable with.

This is an important bridge for teams coming from a relational database background. If you’ve spent years working with SQL Server, Azure SQL, or even PostgreSQL, the idea of learning an entirely new language just to access telemetry or event data can feel like a hurdle.

2026-05-19

When we talk about joining in KQL, we’re usually dealing with a real-time or near-real-time stream of data that needs extra context. The stream itself might contain the facts about what just happened — an event, a transaction, a sensor reading — but to understand that event properly, we often need information that isn’t included in the stream.

That additional context usually comes from a reference or historical table. For example, if you’re processing IoT sensor data, you might want to know what type of device sent the reading, what its normal operating range is, or which location it’s installed in. The stream doesn’t carry that metadata on every message because that would make the data unnecessarily large. Instead, you can use a join to combine the live stream with a reference dataset that contains those attributes.

2026-05-17

A KQL queryset in Microsoft Fabric is essentially a container or workspace for related KQL queries. Instead of having dozens of individual queries saved in isolation, a queryset lets you group them in one logical place so they can be organized, reused, and managed more effectively.

Think of it as a structured collection — you might have a queryset dedicated to application performance monitoring, another for network telemetry, and another for error diagnostics. Each queryset can hold multiple KQL queries, each focused on a specific metric or analysis, but all connected by a common purpose.

2026-05-15

When we work with real-time data in Fabric, not everyone wants to or needs to write KQL or SQL. That’s where visual queries come in.

They provide a no-code interface that lets you build streaming data queries using drag-and-drop actions instead of typing code.

You start with a data source — perhaps an eventstream, a table, or a KQL database — and then visually add steps like filters, joins, or aggregations. Each transformation appears as a node in a flow, so you can see exactly how the data changes from one step to the next. The design is similar to what you might have seen in Power Query or Dataflows, but it’s designed specifically for real-time and streaming data rather than batch processing.

2026-05-11

When we talk about KQL databases in Fabric, we’re referring to databases that are specifically optimized for high-volume, time-series, and log-style data. These databases are designed around the kinds of workloads that come from telemetry, sensors, applications, and services that continuously generate events.

Rather than being general-purpose like a relational database, a KQL database is built to handle append-only, event-driven data at scale — often millions of rows per second. The architecture is different from what we see in traditional SQL databases. Data in a KQL database is typically stored in compressed, columnar form, which makes it extremely efficient to query across large time ranges or to aggregate over millions or billions of records.

2026-05-09

Once your Eventstream is processing data, the next key step is deciding where those events should go — their destinations.

Eventstreams are designed to be flexible: you can route events to multiple destinations at once, both inside Fabric and to external systems. Let’s look at the main ones.

First is the Eventhouse, which provides a high-performance, KQL-based analytical store. It’s ideal when you need to query and visualize live data in real time — for example, detecting anomalies or monitoring live operations. Because it uses KQL, it integrates tightly with Real-Time Dashboards and KQL Querysets in Fabric.

2026-05-07

When it comes to designing an Eventstream pipeline in Fabric, the process generally follows a clear, three-step flow. First, you start with the inputs — the data sources. This might include Kafka, Event Hubs, IoT Hub, or other streaming systems. At this stage, you define the connections and schemas so Fabric knows how to interpret incoming events.

The second step is where you apply transformations. These are the operations that make raw data more usable and more valuable. You might apply filtering to reduce noise and drop irrelevant events. You might use mapping to rename fields, adjust types, or flatten JSON into something cleaner. And you might use routing to branch different types of events to different destinations. Together, these transformations ensure that events are shaped, cleaned, and directed properly before they move downstream.

2026-05-05

Routing is one of the features that makes Eventstreams especially powerful in Fabric. It gives you fine-grained control over where different types of events end up. Instead of building separate ingestion pipelines for every scenario, you can manage multiple flows in one stream and branch the data based on rules you define.

For example, imagine a company that handles both IoT telemetry and financial transactions. IoT data, like sensor readings, is most valuable in a KQL database, where you can run fast time-series analysis and detect anomalies. At the same time, financial transactions are better suited to a warehouse, where structured schemas and BI reporting tools can shine. With routing, both event types can enter the same Eventstream, but the system automatically directs them to the most appropriate destination.

2026-05-03

KQL databases are a specialized storage option in Fabric designed specifically for high-volume event and telemetry data. KQL stands for Kusto Query Language, which comes from the Azure Data Explorer (ADX) engine.

These databases are optimized to handle workloads where you might have billions of small events — like application logs, IoT telemetry, or time-series data — and you need to query them at speed.

Where a warehouse is optimized for structured, relational data and a lakehouse is great for mixing structured and semi-structured data, a KQL database shines when you need to scan and aggregate across massive volumes of events very quickly. You can run queries that look back over millions of log entries or thousands of IoT readings and get sub-second responses. That kind of responsiveness is what makes it possible to power real-time dashboards, alerting systems, and anomaly detection workflows.

2026-05-01

Apache Kafka is one of the most widely used event streaming systems in the world, and for good reason. At its core, Kafka is a distributed, open-source platform that makes it possible to capture, process, and deliver millions of events per second with high reliability.

Kafka organizes data into topics, which you can think of as named channels. A producer writes events into a topic — this could be an application logging user activity, or a payment system recording transactions.

2026-04-29