QuestDB exposes a reader for InfluxDB line protocol which allows using QuestDB as a drop-in replacement for InfluxDB and other systems which implement this protocol. This guide provides practical details of using InfluxDB line protocol to send data to QuestDB, with hints for formatting messages to ensure that QuestDB correctly parses incoming data as the desired data type.
For more details on configuring the QuestDB server with ingestion settings, refer to the InfluxDB API reference.
InfluxDB line protocol messages have the following syntax:
The data of each row is serialized in a "pseudo-CSV" format where each line is composed of the following:
- the table name followed by a comma
- several comma-separated items of tags in the format
<label>=<value>followed by a space
- several comma-separated items of fields in the format
<label>=<value>followed by a space
- an optional timestamp for the record
- a newline character
A single line of text in line protocol format represents one table row QuestDB. Consider the following InfluxDB line protocol message:
This would create a new row in the
sensors table with the following contents:
InfluxDB have the following description of the elements of line protocol:
In the context of QuestDB, the elements of an ILP message are parsed as follows:
Adding multiple symbol and numeric values to messages is done by a comma-separated list:
This ILP message would produce an entry in the
sensors table with the
symbol types from tables completely, the comma and symbol values can
Tag keys and field keys in InfluxDB line protocol messages equate to column names. In QuestDB, column names cannot contain the following characters, and as such, tag and field keys must not contain any of the following characters:
In InfluxDB, table names, tag keys, and field keys cannot begin with an
_. This restriction is not enforced in QuestDB, and therefore
the following InfluxDB line protocol message will produce a valid row in
Note that spaces and commas do not require an escaping backslash in the field
Field values may be parsed by QuestDB as one of the following types:
All subsequent field values must match the type of the first row written to a given column.
For details on the available data types in QuestDB, see the data types reference.
If field values are passed string types, the field values must be double-quoted. Special characters are supported without escaping:
For string types in QuestDB, the storage is allocated as
32+n*16 bits where
n is the string length with a maximum value of
The default numerical type is a 64-bit
double type. To store numeric values as
integers, a trailing
i must follow the value. The following line protocol
message adds a
long type integer column for temperature:
sensors table would have the following row added:
long types as a signed integer from
Boolean values can be passed in InfluxDB line protocol messages with any of the following:
The following example adds a
boolean type column called
It is not necessary to create a table schema for messages passed via InfluxDB line protocol. A table will be dynamically created if one does not exist. If new columns are added as field or tag sets, the table is automatically updated to reflect the new structure and the new column will be back-propagated with null values.
When new tables are created by inserting records via InfluxDB line protocol, a
default partitioning strategy by
DAY is applied.
This default can be overridden by means of passing server configuration for
For information describing how to pass server settings to QuestDB, see the configuration documentation page.
QuestDB can ingest line protocol packets both over TCP and UDP with the following defaults:
- InfluxDB TCP listener on port
- InfluxDB UDP listener on port
For more details on configuring how QuestDB ingests InfluxDB line protocol messages, including setting alternative ports, refer to the following server configuration references:
The following basic Python example demonstrates how to stream InfluxDB line protocol messages to QuestDB over TCP. For more examples using different languages, see the insert data documentation.