Understanding attribute limits in Sanity pricing plans

Do I understand correctly that the pricing plans encourage using structured content more (so having more documents) than using attributes on documents (unique attributes)? 🙂

I've always thought of it as more of a technical limitation. But at any rate, you can't wrong with structured content 😉 In my about 8 projects with Sanity, unique attributes have never been a problem.The only case I can see being problematic is a website that have supports a lot of different languages. But then there are properly better ways to handle this than using attributes.

Attribute limits can be a pretty opaque concept to understand. Generally, the follow (long read, sorry) helps to keep in mind when thinking about them:

The attribute limit is essentially about how many unique paths you have in your dataset. Let's take a structure like this:

{ "foo": [ { "bar":…, "baz":… }, { "bar":…, "baz":… }, { "bat": { "bar":… } } ] }

This leads to the following six attributes:

foo -> an array

foo[] -> an object

foo[].bar -> a string

foo[].baz -> a string

foo[].bat -> an object

foo[].bat.bar -> a string

A simple array of strings will give you a lower attribute count than a block content field, because a block content field has, among others:

the blockContent array, with inside of it:

blocks objects, with inside of them:

markDefs and children arrays, with inside of them:

span types, with inside of them:

a marks array and a text field

This nested structure is further extended by any custom structures you might add to it, each with its own content, so having a bunch of block content fields may lead to a hefty amount of different paths and therefore unique attributes. The same would be true for array fields of complex objects, such as page builders. You may even have block content inside of complex objects inside of arrays. Localisation is another candidate to boost the number of attributes.

In terms of reducing your attribute count, the above examples are good places to start looking. What is also noteworthy is that deleting documents will not lower attribute count, unless you delete every last document that follows a certain schema. The unique paths count the same for one document as for a million using those paths. It's basically about how many paths are occupied by data.

To keep an eye on things while you optimise, you can use this url: https://<projectId>.api.sanity.io/v2021-03-25/data/stats/ <datasetName>. The attribute count is the value of fields.count.value and the limit is inside fields.count.limit.

A final note is that it also helps to remove any unused content from schema revisions. For example, if you used to have a particular document type with a bunch of documents, but later removed that type, or even just some fields within a type, make sure to clean up the content so there are no leftovers in the datastore that will count towards the attribute limit.

This clarifies a lot. Thanks!