Removing max key count, max key length, and max value length in favor of max db size

[jkarlin]

Since shared storage is cross-site data, just knowing the size of your origin's shared storage database could leak significant information. Therefore, Shared Storage is not quota managed, and the size of the origin's database is not web exposed.

Because it's not quota managed, we've put a cap on the size of each origin's shared storage database. But we enforced that cap by limiting the key and value lengths, and the number of possible keys. In retrospect that seems overly constraining to me, when we could instead just have a single size limit for the origin that we enforce, allowing developers to use that space as they see fit.

Any thoughts or comments on making such a change? I don't have anyone asking for this change right now so it's not high priority, but would be interested to hear from folks.

[SpaceGnome]

Seems reasonable to switch to an overall single size limit, but agree doesn't seem high priority given the existing key/value pair limits and their lengths.

[pythagoraskitty]

We are proposing to move ahead with changing the storage quota model as described above.

Previously we allowed a total number of key-value pairs per origin, with keys and values having a maximum character limit of 1024 apiece.

We propose to move instead to a model where each origin would get a total of 5MB of shared storage that they could allocate across key-value pairs according to their needs.

Our goal in doing this is to increase utility/ergonomics for developers, so we welcome feedback about this proposal. Any thoughts or comments?

[jdfreder]

I don't foresee this change causing any problems with unique reach measurement.