Hi Stefan,
The store is a logical and practical partitioning of your data, it is similar to “collections” or “tables” or “buckets”, based on the database technology you’re most familiar with.
Also, each store can have a different ACL allowing only specific users / groups to create documents in it.
While you can put every piece of data you have in one store and then partition based on schemas or a property in each document, it would be better if you partition your data in multiple stores based on functionalities, data types, security or even scalability (like simple sharding).
– Logical Partitioning: in a “shop” solution, you would have your POs in a separate store, not mixed with your catalog.
– Security Partitioning: in an “HR” solution, you would want to put a GATE-ACL (stopping all operations on the store) to the HR group. That way no matter what ACL is set on each document, the store acl will stop them at the gate.
Concerning scalability, when the store grows a lot, some queries might get a performance degradation while it won’t be affected by the size of another store in the same account. This means that you should separate “metadata” like the catalog in the previous example, from the ever growing list of POs (making sure that listing products is only affected by the number of products and not by the number of purchases).
You can also separate your POs into multiple stores, by date or by some other criteria (sharding).
I hope this helps,
Julien Mrad
Scriptr.io Team