Multi-tenant

FireFeed implementa tenancy a livello di schema PostgreSQL. Per ogni Company esistono due namespace derivati dall'ID:

• company_<companyId> per i dati dinamici del Feed Manager;
• oms_<companyId> per i dati operativi ad alto volume dell'OMS.

Cosa vive in public

Le tabelle "control plane":

• users, accounts, sessions (NextAuth)
• companies
• memberships (user × company × ruolo)
• invitations
• api_keys
• projects (metadati: nome, companyId, …)
• database_fields (definizione campi per project)
• imports, exports, connections, rules, rule_groups, schedulers
• pipeline_runs, pipeline_logs
• oms_channels, oms_sync_logs e policy inventory outbound
• endpoint e delivery ledger dei webhook commerce inbound

Cosa vive in company_<companyId>

I dati prodotto effettivi, per company:

• project_<id> — la tabella dati di un progetto (colonne dinamiche dai database_fields)
• staging_<project8>_<import8>[_<run8>] — buffer temporaneo durante l'import
• rules_tmp_<project8>_<export8>_<run8> — set isolato per applicare le regole di un export

Il servizio SchemaService in packages/shared/src/services/schema-service.ts espone le primitive per creare/migrare/distruggere queste tabelle in modo sicuro (sanitizzazione SQL via allow-list).

Cosa vive in oms_<companyId>

Il dominio operativo della company:

• ordini, righe, clienti, fulfillment e reservation;
• magazzini, saldi, ledger, inventari e documenti PZ/WZ/MM;
• spedizioni, colli, tracking, resi e rimborsi;
• domain event, automazioni, outbox e blocker operativi.

Lo schema OMS viene inizializzato on demand e aggiornato con migrazioni tenant forward-only. Le query verificano sempre che lo schema risolto appartenga alla company attiva.

Perché schema-per-company e non row-level

• Performance: indici e statistiche dedicate per tenant; nessun filtro WHERE companyId = ? su ogni query.
• Isolation: una migration sbagliata su uno schema non tocca gli altri; backup/restore granulari.
• Mental model: il dev guardando una query vede un namespace esplicito invece di doversi fidare di un middleware globale.

Il trade-off è una migrazione più complessa tra control plane e schemi tenant. Il SchemaService gestisce creazione e aggiornamento di entrambi i namespace; le migrazioni Prisma dello schema public non sostituiscono le migrazioni tenant OMS.