Documentation

Create a table

Use the influxdb3 create table command or the HTTP API to create a table in a specified database in InfluxDB 3 Enterprise.

With InfluxDB 3 Enterprise, tables and measurements are synonymous. Typically, tables are created automatically on write using the table name specified in line protocol written to InfluxDB. However, you can manually create tables to define a custom schema or apply custom settings before writing data.

Create a table using the influxdb3 CLI

Use the influxdb3 create table command and provide the following:

  • Required: The name of the database to create the table in

  • Required: The name of the table to create (see Table naming restrictions)

  • Required: Tag columns to include in the table (must have at least one tag column)

  • Optional: Field columns and their data types to include in the table

  • Optional: Retention period. If omitted, uses database retention period.

Tables must include at least one tag column. Field columns are optional and can be added later when you write data.

Tag order affects query performance

When considering your schema and creating your table, order your tags by query priority. Place the most commonly queried tags first. Columns that appear earlier are typically faster to filter and access during query execution.

For more information, see Optimize writes.

# Create a table with tag columns
influxdb3 create table \
  --tags tag1,tag2,tag3 \
  --database 
DATABASE_NAME
\
--token
AUTH_TOKEN
\
TABLE_NAME
# Create a table with tag and field columns influxdb3 create table \ --tags room,sensor_id \ --fields temp:float64,hum:float64,co:int64 \ --database
DATABASE_NAME
\
--token
AUTH_TOKEN
\
TABLE_NAME
# Create a table with a 7-day retention period
influxdb3 create table \
  --tags room,sensor_id \
  --fields temp:float64,hum:float64 \
  --retention-period 7d \
  --database 
DATABASE_NAME
\
--token
AUTH_TOKEN
\
TABLE_NAME
# Create a table with database default retention (omit --retention-period) influxdb3 create table \ --tags room,sensor_id \ --database
DATABASE_NAME
\
--token
AUTH_TOKEN
\
TABLE_NAME

Replace the following:

  • DATABASE_NAME: the name of the database to create the table in
  • TABLE_NAME: the name of the table to create
  • AUTH_TOKEN: your admin token

Create a table using the HTTP API

To create a table using the HTTP API, send a POST request to the /api/v3/configure/table endpoint:

POST localhost:8181/api/v3/configure/table

Include the following in your request:

  • Headers:
    • Authorization: Bearer with your authentication token
    • Content-Type: application/json
  • Request body: JSON object with table configuration
    • db (string, required): Database name

    • table (string, required): Table name

    • tags (array, required): Tag column names

    • fields (array, optional): Field definitions with name and type

    • retention_period (string, optional): Retention period. If omitted, uses database retention period.

# Create a table with tag columns
curl -X POST "localhost:8181/api/v3/configure/table" \
  --header "Authorization: Bearer 
AUTH_TOKEN
"
\
--header "Content-Type: application/json" \ --data '{ "db": "
DATABASE_NAME
",
"table": "
TABLE_NAME
",
"tags": ["tag1", "tag2", "tag3"] }' # Create a table with tag and field columns curl -X POST "localhost:8181/api/v3/configure/table" \ --header "Authorization: Bearer
AUTH_TOKEN
"
\
--header "Content-Type: application/json" \ --data '{ "db": "
DATABASE_NAME
",
"table": "
TABLE_NAME
",
"tags": ["room", "sensor_id"], "fields": [ {"name": "temp", "type": "float64"}, {"name": "hum", "type": "float64"}, {"name": "co", "type": "int64"} ] }'
# Create a table with a 7-day retention period
curl -X POST "localhost:8181/api/v3/configure/table" \
  --header "Authorization: Bearer 
AUTH_TOKEN
"
\
--header "Content-Type: application/json" \ --data '{ "db": "
DATABASE_NAME
",
"table": "
TABLE_NAME
",
"tags": ["room", "sensor_id"], "fields": [ {"name": "temp", "type": "float64"}, {"name": "hum", "type": "float64"} ], "retention_period": "7d" }' # Create a table with database default retention (omit retention_period) curl -X POST "localhost:8181/api/v3/configure/table" \ --header "Authorization: Bearer
AUTH_TOKEN
"
\
--header "Content-Type: application/json" \ --data '{ "db": "
DATABASE_NAME
",
"table": "
TABLE_NAME
",
"tags": ["room", "sensor_id"] }'

Replace the following:

  • DATABASE_NAME: the name of the database to create the table in
  • TABLE_NAME: the name of the table to create
  • AUTH_TOKEN: your admin token

Retention period

By default, tables use the database retention period. When creating a table, set a table-specific retention period to automatically delete expired data and optimize storage for that table.

A table retention period overrides the database retention period for that specific table. This allows you to maintain different retention policies for different types of data within the same database.

Retention period syntax

The retention period value is a time duration value made up of a numeric value plus a duration unit. For example, 7d means 7 days. The retention period value cannot be negative or contain whitespace.

Valid durations units include

  • m: minute
  • h: hour
  • d: day
  • w: week
  • mo: month
  • y: year

Retention period constraints

  • Minimum for data retention: The practical minimum retention period is 1 hour (1h).
  • Zero-duration periods: Setting a retention period to 0<unit> (for example, 0d or 0h) is allowed but marks all data for immediate deletion at query time. This differs from InfluxDB 1.x and 2.x where 0d meant infinite retention.
  • Infinite retention: Use none to set an infinite retention period.

Retention period precedence

When both a database and a table have retention periods defined, the table retention period takes precedence for that specific table.

Example scenarios:

  • Short-term data in long-term database: Store high-volume sensor data with 7-day retention in a database with 90-day retention
  • Long-term data in short-term database: Store audit logs with 1-year retention in a database with 30-day retention
  • Mixed retention requirements: Maintain both real-time metrics (7 days) and aggregated metrics (1 year) in the same database

For complete details about retention period precedence and behavior, see Data retention in InfluxDB 3 Enterprise.

Table naming restrictions

Table names in InfluxDB 3 Enterprise must adhere to the following naming restrictions:

  • Allowed characters: Alphanumeric characters (a-z, A-Z, 0-9), underscore (_), dash (-)
  • Starting character: Should start with a letter or number and should not start with underscore (_)
  • Case sensitivity: Table names are case-sensitive
  • Quoting: Use double quotes when names contain special characters or whitespace

Underscore prefix reserved for system use

Names starting with an underscore (_) may be reserved for InfluxDB system use. While InfluxDB 3 Enterprise might not explicitly reject these names, using them risks conflicts with current or future system features and may result in unexpected behavior or data loss.


Was this page helpful?

Thank you for your feedback!


New in InfluxDB 3.5

Key enhancements in InfluxDB 3.5 and the InfluxDB 3 Explorer 1.3.

See the Blog Post

InfluxDB 3.5 is now available for both Core and Enterprise, introducing custom plugin repository support, enhanced operational visibility with queryable CLI parameters and manual node management, stronger security controls, and general performance improvements.

InfluxDB 3 Explorer 1.3 brings powerful new capabilities including Dashboards (beta) for saving and organizing your favorite queries, and cache querying for instant access to Last Value and Distinct Value caches—making Explorer a more comprehensive workspace for time series monitoring and analysis.

For more information, check out:

InfluxDB Docker latest tag changing to InfluxDB 3 Core

On November 3, 2025, the latest tag for InfluxDB Docker images will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments.

If using Docker to install and run InfluxDB, the latest tag will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments. For example, if using Docker to run InfluxDB v2, replace the latest version tag with a specific version tag in your Docker pull command–for example:

docker pull influxdb:2