A prima vista, il design non è molto efficiente, ma l'avvertenza è che è difficile essere precisi senza conoscere i requisiti di scalabilità e ridondanza.
La multi-tenancy è un punto interrogativo per me. Il tuo intento è di avere un database separato per cliente. Come sarebbe quella scala con il numero di clienti?
Ad esempio, supponiamo di avere un piccolo cliente A con un modello di utilizzo frequente e un cliente in sospeso di grandi dimensioni B. Con due istanze separate, l'istanza Postgres del cliente B potrebbe utilizzare la RAM inutilmente.
Quindi, è abbastanza comune nei servizi SaaS scegliere istanze multi-tenant, in cui tutti gli account condividono lo stesso DB. Ciò consente al DB di eseguire una strategia di memorizzazione nella cache migliore e semplifica la ridondanza, in cui è necessario replicare un DB anziché X DB.
Un'altra domanda riguarda la scalabilità . postgresSQL è un RDBMS classico - niente di sbagliato in questo. Ma se ti aspetti un momento nella vita del tuo progetto in cui una singola VM / hardware non sarà in grado di contenere tutti i tuoi dati, sarà il momento di pensare a sharding, replicazione ecc., Che potrebbe essere una sfida.
In generale, il mio consiglio sarebbe guardare piani di crescita pragmatici, scala di obiettivi e revisione postgres insieme a NoSQL DB , mentre sbirciare al < a href="https://en.wikipedia.org/wiki/CAP_theorem"> Teorema CAP .
Un altro angolo è il crunch dei dati e la concorrenza . Se mapreduce è nel tuo elenco di considerazioni, potrebbe spingerti a una scelta di back-end che fornisce un buon quadro di riduzione della mappa.
Ancora una volta, potrebbe essere che scoprirai che postgres è più che adeguato per l'attività, e che hai già considerato la maggior parte di questi.