InfluxDB data elements

InfluxDB 2.7 includes the following data elements:

The sample data below is used to illustrate data elements concepts. Hover over highlighted terms to get acquainted with InfluxDB terminology and layout.

bucket: my_bucket

_time _measurement location scientist _field _value
2019-08-18T00:00:00Z census klamath anderson bees 23
2019-08-18T00:00:00Z census portland mullen ants 30
2019-08-18T00:06:00Z census klamath anderson bees 28
2019-08-18T00:06:00Z census portland mullen ants 32


All data stored in InfluxDB has a _time column that stores timestamps. On disk, timestamps are stored in epoch nanosecond format. InfluxDB formats timestamps show the date and time in RFC3339 UTC associated with data. Timestamp precision is important when you write data.


The _measurement column shows the name of the measurement census. Measurement names are strings. A measurement acts as a container for tags, fields, and timestamps. Use a measurement name that describes your data. The name census tells us that the field values record the number of bees and ants.


A field includes a field key stored in the _field column and a field value stored in the _value column.

Field key

A field key is a string that represents the name of the field. In the sample data above, bees and ants are field keys.

Field value

A field value represents the value of an associated field. Field values can be strings, floats, integers, or booleans. The field values in the sample data show the number of bees at specified times: 23, and 28 and the number of ants at a specified time: 30 and 32.

Field set

A field set is a collection of field key-value pairs associated with a timestamp. The sample data includes the following field sets:

census bees=23i,ants=30i 1566086400000000000
census bees=28i,ants=32i 1566086760000000000
           Field set

Fields aren’t indexed: Fields are required in InfluxDB data and are not indexed. Queries that filter field values must scan all field values to match query conditions. As a result, queries on tags > are more performant than queries on fields. Store commonly queried metadata in tags.


The columns in the sample data, location and scientist, are tags. Tags include tag keys and tag values that are stored as strings and metadata.

Tag key

The tag keys in the sample data are location and scientist. For information about tag key requirements, see Line protocol – Tag set.

Tag value

The tag key location has two tag values: klamath and portland. The tag key scientist also has two tag values: anderson and mullen. For information about tag value requirements, see Line protocol – Tag set.

Tag set

The collection of tag key-value pairs make up a tag set. The sample data includes the following four tag sets:

location = klamath, scientist = anderson
location = portland, scientist = anderson
location = klamath, scientist = mullen
location = portland, scientist = mullen

Tags are indexed: Tags are optional. You don’t need tags in your data structure, but it’s typically a good idea to include tags. Because tags are indexed, queries on tags are faster than queries on fields. This makes tags ideal for storing commonly queried metadata.

Tags containing highly variable information like UUIDs, hashes, and random strings will lead to a large number of unique series in the database, known as high series cardinality. High series cardinality is a primary driver of high memory usage for many database workloads. See series cardinality for more information.

Why your schema matters

If most of your queries focus on values in the fields, for example, a query to find when 23 bees were counted:

from(bucket: "bucket-name")
    |> range(start: 2019-08-17T00:00:00Z, stop: 2019-08-19T00:00:00Z)
    |> filter(fn: (r) => r._field == "bees" and r._value == 23)

InfluxDB scans every field value in the dataset for bees before the query returns a response. If our sample census data grew to millions of rows, to optimize your query, you could rearrange your schema so the fields (bees and ants) becomes tags and the tags (location and scientist) become fields:

_time _measurement bees _field _value
2019-08-18T00:00:00Z census 23 location klamath
2019-08-18T00:00:00Z census 23 scientist anderson
2019-08-18T00:06:00Z census 28 location klamath
2019-08-18T00:06:00Z census 28 scientist anderson
_time _measurement ants _field _value
2019-08-18T00:00:00Z census 30 location portland
2019-08-18T00:00:00Z census 30 scientist mullen
2019-08-18T00:06:00Z census 32 location portland
2019-08-18T00:06:00Z census 32 scientist mullen

Now that bees and ants are tags, InfluxDB doesn’t have to scan all _field and _value columns. This makes your queries faster.

Bucket schema

In InfluxDB Cloud, a bucket with the explicit schema-type requires an explicit schema for each measurement. Measurements contain tags, fields, and timestamps. An explicit schema constrains the shape of data that can be written to that measurement.

The following schema constrains census data:

name type data_type
time timestamp
location tag string
scientist tag string
ants field integer
bees field integer


Now that you’re familiar with measurements, field sets, and tag sets, it’s time to discuss series keys and series. A series key is a collection of points that share a measurement, tag set, and field key. For example, the sample data includes two unique series keys:

_measurement tag set _field
census location=klamath,scientist=anderson bees
census location=portland,scientist=mullen ants

A series includes timestamps and field values for a given series key. From the sample data, here’s a series key and the corresponding series:

# series key
census,location=klamath,scientist=anderson bees

# series
2019-08-18T00:00:00Z 23
2019-08-18T00:06:00Z 28        

Understanding the concept of a series is essential when designing your schema and working with your data in InfluxDB.


A point includes the series key, a field value, and a timestamp. For example, a single point from the sample data looks like this:

2019-08-18T00:00:00Z census ants 30 portland mullen


All InfluxDB data is stored in a bucket. A bucket combines the concept of a database and a retention period (the duration of time that each data point persists). A bucket belongs to an organization. For more information about buckets, see Manage buckets.


An InfluxDB organization is a workspace for a group of users. All dashboards, tasks, buckets, and users belong to an organization. For more information about organizations, see Manage organizations.

If you’re just starting out, we recommend taking a look at the following guides:

For an overview of how these elements interconnect within InfluxDB’s data model, watch the following video:

Was this page helpful?

Thank you for your feedback!

Introducing InfluxDB Clustered

A highly available InfluxDB 3.0 cluster on your own infrastructure.

InfluxDB Clustered is a highly available InfluxDB 3.0 cluster built for high write and query workloads on your own infrastructure.

InfluxDB Clustered is currently in limited availability and is only available to a limited group of InfluxData customers. If interested in being part of the limited access group, please contact the InfluxData Sales team.

Learn more
Contact InfluxData Sales

The future of Flux

Flux is going into maintenance mode. You can continue using it as you currently are without any changes to your code.

Flux is going into maintenance mode and will not be supported in InfluxDB 3.0. This was a decision based on the broad demand for SQL and the continued growth and adoption of InfluxQL. We are continuing to support Flux for users in 1.x and 2.x so you can continue using it with no changes to your code. If you are interested in transitioning to InfluxDB 3.0 and want to future-proof your code, we suggest using InfluxQL.

For information about the future of Flux, see the following:

State of the InfluxDB Cloud Serverless documentation

InfluxDB Cloud Serverless documentation is a work in progress.

The new documentation for InfluxDB Cloud Serverless is a work in progress. We are adding new information and content almost daily. Thank you for your patience!

If there is specific information you’re looking for, please submit a documentation issue.