Is it possible to check for how many unique attributes are being used in a specific sanity database?

Yes, you can check how many unique attributes are being used in your Sanity project! Here's what you need to know:

Checking Your Current Attribute Count

You can monitor your project's unique attribute count by accessing the stats API endpoint:

<projectId>.api.sanity.io/v1/data/stats/<datasetName>

Replace <projectId> with your actual project ID and <datasetName> with your dataset name (typically "production"). For example: abc123.api.sanity.io/v1/data/stats/production

In the JSON response, look for fields.count.value - this shows your current unique attribute count. You'll also see fields.count.limit which shows your plan's maximum.

Understanding Attribute Limits by Plan

The attribute limits vary based on your Sanity plan:

• Free plan: 2,000 unique attributes (dataset-level)
• Growth plan: 10,000 unique attributes (dataset-level)
• Enterprise plan: Custom # attributes (negotiable)

There are also per-document limits:

• Free/Growth plans: 1,000 attributes per document
• Enterprise plan: 8,000 attributes per document

What Counts as a Unique Attribute?

An attribute is defined as a unique combination of attribute path and datatype. Think of them as the different paths through your content structure:

{
  "foo": [
    {
      "bar": "text",
      "baz": "more text"
    }
  ]
}

This counts as 5 unique attributes:

• foo → array
• foo[] → object
• foo[].bar → string
• foo[].baz → string

Important: Attributes are only counted when they hold actual content. Just changing your schema definitions won't affect the count - you need to actually add or remove content using Studio or the API.

Using GROQ to Explore Your Data

While GROQ doesn't have a built-in "count unique attributes" function, you can use the Vision plugin to query and explore your content structure. The stats endpoint mentioned above is the official way to get the exact count.

Best Practices to Stay Under the Limit

If you're approaching your limit, consider:

• Use arrays instead of block content for page building to reduce nested paths
• Avoid excessive nesting - keep structures relatively flat
• Focus on meaning, not presentation - don't duplicate CSS-like properties in your schema
• Duplicate documents, not fields for internationalization (instead of wrapping all fields in language objects)

The stats API is your best friend for monitoring this - check it periodically during development, especially if you're building complex, nested content models!