La nostra guida al backend conforme al GDPR e sovrana dell'UE definisce il quadro giuridico completo: GDPR, CLOUD Act e perché controllare solo una regione di hosting non è mai sufficiente. Questo articolo estende la sua sezione sull'arbitrato delle PMI con l'effettivo onere operativo di ciascuna opzione, piuttosto che riprodurre la teoria legale. Se la tua domanda riguarda i backend Rust self-hosting, sh0.dev, TrailBase, Aurabase, il nostro confronto dedicato Aurabase e BaaS nativo di Rust affronta questo distinto angolo architettonico. Ciò rimane focalizzato sulla decisione GDPR per una PMI, indipendentemente dal linguaggio di backend.
L'essenziale
- Due opzioni sono conformi al GDPR sulla carta, il self-hosting dell’UE e il BaaS sovrano dell’UE: ciò che le differenzia è l’onere operativo trasferito, non la conformità stessa.
- Il self-hosting richiede un team in grado di applicare continuamente patch, eseguire il backup, monitorare e documentare Postgres. Questo onere non scompare mai: passa semplicemente di mano a un fornitore esterno.
- Un BaaS americano con opzione regione UE risolve solo la metà del problema: la nazionalità dell’azienda che lo gestisce rimane soggetta al CLOUD Act, indipendentemente dalla regione scelta.
- Il CTO di una PMI generalmente decide tra build interna, Supabase Cloud, AWS Amplify e una soluzione sovrana dell'UE: la scelta giusta dipende soprattutto dalla capacità del team disponibile.
- Aurabase copre entrambi i modelli: BaaS gestito sovrano dall'UE (Hetzner, Germania e Finlandia) o self-hosting tramite Kubernetes (k3d localmente) e Helm, sotto licenza MIT.
Ciò che distingue davvero le due opzioni
Un backend self-hosted in un data center europeo e un BaaS sovrano dell'UE possono entrambi spuntare le stesse caselle GDPR: sede nell'UE, società operativa europea, DPA disponibile (lato fornitore) o registro interno aggiornato (lato self-hosted). Il GDPR non ha alcuna preferenza architetturale tra i due. Ciò che cambia veramente è chi assorbe il carico operativo quotidiano: patch di sicurezza, backup testati, reperibilità, supervisione continua.
Il quadro giuridico completo, GDPR e CLOUD Act, è dettagliato nella nostra guida al backend conforme al GDPR e sovrano dell'UE. Ciò che questa guida non approfondisce è il costo operativo reale di ciascuna opzione per un team che non dispone necessariamente di un SRE dedicato. Questo è l'angolo di questo articolo.
Self-hosting: cosa deve realmente farsi carico di una PMI
L'hosting autonomo di un backend Postgres trasferisce la completa responsabilità operativa al tuo team, non solo al server. Concretamente, quattro attività vengono ripetute ripetutamente: applicare le patch di sicurezza Postgres non appena vengono pubblicate e testare regolarmente il ripristino del backup, non solo pianificarlo. È inoltre necessario monitorare continuamente la disponibilità, oppure accettare tempi di risposta più lunghi e ruotare i segreti e le chiavi di accesso secondo una pianificazione documentata.
Questi compiti non scompaiono mai, nemmeno nel self-hosting. Rimarrai anche il tuo subappaltatore tecnico nei confronti del tuo host (Hetzner, OVH, Scaleway o altro). Presso di esso deve esistere un DPA e il vostro registro dei trattamenti (art. 30 GDPR) deve documentare questa catena. Una PMI senza un team infrastrutturale dedicato spesso sottovaluta quest’ultimo punto.
BaaS sovrano dell’UE: cosa viene trasferito, cosa resta tuo
Un BaaS sovrano dell'UE trasferisce le patch, l'infrastruttura di backup e il monitoraggio della disponibilità al fornitore, sotto la copertura di un DPA datato e verificabile (articolo 28 GDPR). È l'onere operativo descritto al punto precedente che passa di mano, non la responsabilità legale.
Il titolare del trattamento rimani tu, indipendentemente dal fornitore scelto (Art. 24 GDPR). Base giuridica del trattamento, minimizzazione dei dati raccolti, notifica della violazione all'autorità di controllo entro 72 ore (art. 33 GDPR): queste decisioni restano a tua carico. Un BaaS sovrano dell’UE riduce il tempo necessario per fornire prova di conformità a un DPO o a un cliente. Ciò non elimina l'obbligo di averne uno.
La terza scelta che spesso dimentichiamo: un BaaS americano, regione UE
Molti team confrontano solo due opzioni mentre una terza pesa nella loro decisione reale: un hyperscaler o un BaaS secondo la legge americana, configurato in una regione europea. AWS Amplify con una regione eu-west-1, o un servizio equivalente, riduce la latenza e soddisfa i requisiti di residenza dei dati. Ma ciò non cambia la nazionalità della società che lo gestisce.
Una società di diritto americano rimane soggetta al CLOUD Act, indipendentemente dalla regione scelta dai suoi clienti. Questo punto è sviluppato in dettaglio nella nostra guida Conforme al GDPR e backend sovrano dell'UE e nel nostro articolo dedicato perché il CLOUD Act cambia la scelta del tuo BaaS. Conta nell'arbitrato di una PMI, anche quando questa opzione sembra la più semplice a breve termine.
Self-hosting, BaaS statunitense nella regione dell'UE, BaaS sovrano dell'UE: confronto
Ecco le tre opzioni attualmente disponibili per una PMI oggi, confrontate sui criteri che pesano di più in una decisione architettonica, non solo sulla casella regionale selezionata.
| Criterio | Auto-alloggio UE | BaaS USA, regione UE | BaaS sovrano dell'UE |
|---|---|---|---|
| Adeguamento GDPR su carta | Sì, se documentato internamente | Sì, se documentato | Sì, se documentato |
| Mostra CLOUD Act | Void (nessuna società statunitense terza) | Actual (società madre americana) | Nullo (società madre UE) |
| Patching e servizio di reperibilità | Integrale, portato internamente | Trasferito al fornitore | Trasferito al fornitore |
| Prova di conformità disponibile | Registro interno per mantenerti | Fornitore DPA, quadro statunitense | DPA del fornitore, datato e verificabile |
| È richiesto il team infrastrutturale | Si consiglia SRE/ops dedicato | Singolo sviluppatore, solitamente sufficiente | Singolo sviluppatore, solitamente sufficiente |
| Velocità nella produzione | Più lento, infrastrutture da costruire | Veloce | Veloce |
Il costo che il self-hosting non mette mai in bolletta
Il costo reale del self-hosting non può essere letto sulla fattura del server. Lo si può leggere nel tempo sottratto all'ingegnere dal prodotto e nell'esposizione legale diretta in caso di incidente.
Una PMI self-hosted diventa sia responsabile del trattamento dei dati che il proprio subappaltatore tecnico. Una mancata patch Postgres o un backup mai testato diventano direttamente imputabili al titolare del trattamento stesso (art. 83 GDPR), senza una catena contrattuale del DPA che si opponga alla document diligence. Per un fornitore BaaS sovrano dell’UE, lo stesso fallimento rimane un’esposizione reale. Ma fa parte di un contratto datato che un DPO o un revisore dei conti può verificare in pochi minuti, più che di una storia interna da ricostruire.
Quando il self-hosting resta la scelta giusta
Il self-hosting rimane rilevante per un ETI o un account di grandi dimensioni che dispone già di un team SRE/operativo e di reperibilità funzionale. Ciò vale anche per un settore in cui la sovranità non tollera alcuna catena di subappalto esterno: settore pubblico, difesa, alcune strutture sanitarie. Il controllo diretto del server fisico ha la precedenza sulla velocità di produzione.
Un’azienda che ha già investito in un’infrastruttura interna Kubernetes o Postgres, con le competenze per mantenerla, ammortizza più facilmente questa scelta rispetto ad una PMI che parte da zero.
Quando un BaaS sovrano dell’UE è la scelta giusta
Un BaaS sovrano dell’UE è la scelta giusta per una PMI senza un team infrastrutturale dedicato, che ha bisogno di dimostrare rapidamente la conformità a un cliente o a un DPO. Preferisce quindi dedicare il suo tempo di progettazione al prodotto piuttosto che alle patch di Postgres. È anche la scelta rilevante per un team che dà priorità alla velocità di rilascio rispetto al controllo totale dello stack.
Dipendi dalla disponibilità di un fornitore e il tuo spazio di negoziazione contrattuale dipende dalle sue dimensioni e maturità. Controlla la sua lista di controllo di conformità prima di firmare, non solo la sua promessa di vendita.
Aurabase: entrambi i modelli sotto lo stesso core Postgres
Aurabase non fissa questa scelta in una direzione. La piattaforma esiste in BaaS gestito sovrano dall'UE, infrastruttura di produzione verificata in Germania (Norimberga, Falkenstein) e in Finlandia (Helsinki) tramite Hetzner, gestita da Aurabase SAS, società di diritto francese. Esiste anche in self-hosting: il repository prevede un cluster Kubernetes locale (k3d) lanciato tramite ./start.sh, e un grafico Helm completo per Kubernetes, il tutto sotto licenza MIT.
Lo stesso motore PostgreSQL 16, le stesse policy RLS e lo stesso SDK si applicano su entrambi i lati: la migrazione da un modello all'altro non richiede la riscrittura dello schema. Per un confronto tra questa modalità self-hosted e altri backend mono-binari Rust-native (sh0.dev, TrailBase), il nostro articolo Sovereign self-hosting: Aurabase versus Rust-native BaaS esplora questo aspetto dell'architettura in dettaglio. Ciò rimane focalizzato sulla decisione GDPR.
Lista di controllo veloce prima di decidere
Quattro domande operative da porsi prima di scegliere, oltre alla checklist di verifica dei fornitori nella nostra guida GDPR.
| 01 | Avete una persona di guardia in grado di applicare patch a un CVE Postgres critico durante un fine settimana? |
|---|---|
| 02 | L'ultimo ripristino del backup è stato testato e non solo pianificato? |
| 03 | Potete produrre un DPA aggiornato per ciascun subappaltatore tecnico di cui vi avvalete? |
| 04 | Un DPO o un cliente possono ottenere la prova di conformità in meno di una settimana? |
Per l'elenco di controllo completo sulla verifica del fornitore, comprese le questioni legali, consulta il nostro elenco di controllo sulla conformità GDPR per un BaaS. Per il livello di sicurezza tecnica associato, vedere Pagina Sicurezza Aurabase.