1. 6
  1.  

  2. 3

    SELECT master_create_distributed_table(‘stores’, ‘id’, ‘hash’);

    I know you want to avoid joins crossing server boundaries, but this config is a mistake. The problem with this is that sharding at the account level means you can’t scale any customer past the size of your single largest server (and you’ll probably have to jump through hoops to assign and migrate them to that server and keep other customers off). It’s an interesting coincidence that you chose this domain for your example because it looks like Shopify, which had exactly this problem.

    1. 3

      Indeed you are then limited to how large of an instance you can scale up a single customer on, but for many this is a perfectly reasonable bound. As for how do you move them to their own server we have some functionality specifically for that (https://www.citusdata.com/blog/2017/03/15/a-look-at-isolating-tenants/). It does admittedly come back to how large your overall dataset is likely to be, then how large each customer is likely to be. If all your data across all your customers is 10 GB then of course sharding makes no sense at all.