# Cardinality v2 versus v1

**URL:** <https://community.influxdata.com/t/cardinality-v2-versus-v1/27296>\
**Category:** InfluxDB 2\
**Created:** [November 8, 2022, 9:22am UTC](https://community.influxdata.com/t/cardinality-v2-versus-v1/27296 "2022-11-08T09:22:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![rvdheij](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/rvdheij/32/1789_2.png) [@rvdheij](https://community.influxdata.com/u/rvdheij)\
**Post date:** [November 8, 2022, 9:22am UTC](https://community.influxdata.com/t/cardinality-v2-versus-v1/27296/1 "2022-11-08T09:22:14Z")

</div>

Using InfluxDB v1.8 right now, and looking at moving to InfluxDB v2. While doing some experiments in InfluxDB Cloud, it complained about cardinality already, and I’m just getting started… Am I correct that “field keys” (v1 terminology) count towards cardinality in v2, as if all metrics are stored in a table with just one column?  
The reason I embraced InfluxDB is because I have quite a few “wide” measurements, some even a few dozen different fields per measurement. For one of my test cases (for a single system):

- 22 measurements selected
- 19 measurements produced (because we don’t have all resources)
- 1433 series (measurement plus tags)
- 162 unique (measurement, field-key) pairs
- 113 unique field-keys
- 13752 unique (measurement plus tags, field-key) pairs

Where v1.8 was just happy with the 1433, v2 seems concerned about the 13,752 cardinality. I think this shows that on average I have 10 fields per series.

For real-life deployment, we would have 100 times more series, and cardinality of 150,000 seems doable with v1. But 10-20 times more in v2 might not be so bright. Should I worry? -Rob

---

<div class="post-metadata">

**Author:** ![Giovanni\_Luisotto](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/giovanni_luisotto/32/4017_2.png) [@Giovanni\_Luisotto](https://community.influxdata.com/u/Giovanni_Luisotto)\
**Post date:** [November 8, 2022, 9:35am UTC](https://community.influxdata.com/t/cardinality-v2-versus-v1/27296/2 "2022-11-08T09:35:26Z")

</div>

You can find a comprehensive answer here:

> [@Series cardinality calculation](https://community.influxdata.com/t/series-cardinality-calculation/27060/5):
>
> @matias In InfluxDB OSS (both 1.x and 2.x), a series is defined by a common measurement and tag set (not field key). In InfluxDB Cloud, the field key is considered part of the series definition. This is because field keys are indexed in InfluxDB Cloud, but they are not indexed in InfluxDB OSS. The reason cardinality matters is due to the efficiency of the index. If there’s too much cardinality in the database as a whole, the index can grow very large and InfluxDB will start to consume a lot of …

---

<div class="post-metadata">

**Author:** ![rvdheij](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/rvdheij/32/1789_2.png) [@rvdheij](https://community.influxdata.com/u/rvdheij)\
**Post date:** [November 8, 2022, 9:55am UTC](https://community.influxdata.com/t/cardinality-v2-versus-v1/27296/3 "2022-11-08T09:55:35Z")

</div>

Thank you, I had not expected the difference between InfluxDB Cloud and InfluxDB v2 OSS (when I correctly interpret the response). Since Paul Dix promised infinite cardinality with IOx, we’ll probably have to wait for that before looking at InfluxDB Cloud.  
The Flux snippet returned exactly the same 13752 that I had computed from the data before writing it. 🙂