How to create a table in KQL and ingest data: example

João Barros 05 de July de 2026 4 min read

Before you can query real-time data, you need somewhere to store it. Creating a table in KQL and ingesting a few sample records is the first practical step in any Real-Time Intelligence project in Microsoft Fabric. With just two commands, you get a table that is ready to receive data and answer your first queries.

Prerequisites

A Microsoft Fabric workspace with active capacity.
An Eventhouse with a KQL Database already created.
Permissions to run management commands (control commands) on that database.
Basic KQL knowledge — if you have never written a query, don't worry, the examples are simple.

Step 1: Open the KQL Queryset

In Microsoft Fabric, real-time data lives in an Eventhouse, which contains one or more KQL databases. Open your KQL database and use the query tab to open a KQL Queryset. This editor is where you run both management commands (starting with a dot) and queries. Before you continue, confirm in the top corner that the correct database is selected, so you don't create the table in the wrong place.

Step 2: Create the table with .create table

To create a table in KQL, use the .create table command, giving the table name and, in parentheses, the name and type of each column. Let's create a simple table for sensor readings, with a timestamp, a device identifier and a temperature.

.create table Leituras (
    Timestamp: datetime,
    Dispositivo: string,
    Temperatura: real
)

The most common types in KQL are datetime, string, int, long, real and bool. Always use datetime for time columns: that is the type that later lets you filter and group your data by period. After you run the command, the table appears in the side list, still empty.

Step 3: Ingest sample data with .ingest inline

With the table created, we can insert a few records by hand with .ingest inline. Each line is one record, and the values follow exactly the same order as the columns, separated by commas.

.ingest inline into table Leituras <|
2026-07-05T08:00:00Z,sensor-01,21.4
2026-07-05T08:05:00Z,sensor-01,21.9
2026-07-05T08:05:00Z,sensor-02,23.1
2026-07-05T08:10:00Z,sensor-02,22.7

Notice the date format: 2026-07-05T08:00:00Z follows the ISO 8601 standard, and the trailing Z means UTC time. This inline method is ideal for tests and demos. In production, data usually arrives through an Eventstream or from files, but the target table is created in exactly the same way.

Tip: management commands start with a dot (.create, .ingest) and queries start with the table name. Run each block separately — mixing the two is a common beginner error.

Step 4: Run your first query

Now that the table has data, try a simple query. The take operator returns a few rows so you can quickly see the content:

Leituras
| take 10

If everything went well, you see the four readings you ingested, with the three columns you defined. From here, you can start filtering by device or by time range.

Verify the result

To confirm the data was really stored, count the records in the table:

Leituras
| summarize Total = count()

You should get 4, the exact number of rows you ingested. To see the schema — the columns and their types — run Leituras | getschema and check that it matches what you defined in Step 2. If the number is off, make sure you ran the .ingest command on the correct database.

Conclusion

With two commands you created a KQL table and loaded data ready to explore — the foundation for real-time dashboards, functions and alerts. The natural next step is to learn how to filter and group these readings by time period, turning loose records into useful trends. What would your first question be: which sensor is the hottest, or how the temperature changes over the day?