Tag or Field: InfluxDB Schema Trade-off for High-Churn Identifiers

Storing a high-churn identifier such as a session ID or UUID in InfluxDB presents a schema trade-off when a dataset that passes local testing will face much higher series cardinality in production. Tags are indexed and become part of the series key, so filtering or grouping by a tag uses the index; fields are not indexed, so queries against them scan the measurement. The unresolved decision is whether to accept the index memory and compaction cost of a tag to preserve query efficiency, or keep the identifier as a field to bound cardinality and redesign the access pattern.

InfluxDB 2.x and 3.x use different storage engines and cardinality models, so the same schema is not portable between versions, and exact limits or defaults must be verified per deployment. Additional uncertainty comes from field type conflicts: changing a value between integer and string causes point rejection unless the field or measurement is versioned, which constrains how the identifier can evolve.

Given these constraints, what is the most reliable way to decide between a tag and a field for a high-churn identifier when the production series count is unknown? How should the decision account for version-specific engine behavior between InfluxDB 2.x and 3.x? What verification steps are appropriate to confirm that the chosen schema will not degrade under production load before it is promoted?