Has anyone tried testing the storage limits of Portal?

Question

So I'm curious to see if anyone has tested to see how Portal performs as the number of items grow really large. A million anyone, 10 million?

* As I understand it (correct me if I'm wrong), Portal is backed by a Postgres database for storing item metadata and file items as BLOB's. So it seems to me that Portal should be able to hold a lot of items.
* Is anyone using Portal as a document management systems of sorts, i.e. storing non-spatial documents related to map features in Portal, that are tagged using a UID of whichever feature they relate to? I could envision a number of useful scenarios.

Arne_Gelfert · Answer

Thanks, Jonathan - good information.

JonathanQuinn · Answer

We support the content directory residing in Azure BLOB storage, so perhaps that's where that came from?

There shouldn't be a problem in normal, day to day operations. Upgrading may take time as it needs to backup the content directory and reindexing will take time. But theoretically, yes, you could link to an item in the Portal rather than in a web server, (C:\inetpub\wwwroot, for example).

Arne_Gelfert · Answer

Thanks for the clarifications. I had read the BLOB bit somewhere but I guess my own screenshot should've alerted me that the files go in the directory and only meta data goes in DB.

Yes, exactly. I was wondering how 100K's or 1M's of items would perform. Thinking now about all the necessary directory under the Content folder, that makes me even more curious. Say you have a 100K features, and each one has 10-100 documents... In the past, I've been told that if you want to link from spatial feature to related documents via href in the attributes, the associated files would have to live on the ArcGIS server ... so wondering if linking to Portal items would work better. Anyway, it's not something I'm about to implement. more brainstorming.