Vercel e Supabase in produzione: costi, GDPR e lock-in

Vercel e Supabase permettono a un piccolo team di pubblicare un’applicazione con frontend, funzioni, database, autenticazione e storage in tempi molto brevi. È un vantaggio concreto: meno infrastruttura iniziale, un’esperienza di sviluppo coerente e servizi gestiti che sarebbero costosi da costruire da zero.

Il prototipo gratuito, però, mostra soprattutto la velocità di partenza. La produzione introduce volumi, obblighi sui dati, obiettivi di ripristino e dipendenze tra servizi. La scelta non è «piattaforme buone o cattive», ma se costi, responsabilità e uscita sono compatibili con il prodotto.

Dal piano gratuito a un modello di consumo

Un preventivo serio non parte dal prezzo del piano, ma dalle unità che l’architettura consuma. Le tariffe e le quote cambiano: per questo conviene mantenere un foglio di stima datato e verificare la documentazione ufficiale prima di ogni decisione commerciale.

Le metriche da modellare su Vercel

• compute: durata di esecuzione, memoria allocata, concorrenza e regione delle funzioni;
• invocazioni e richieste edge: frequenza con cui traffico, middleware e logica dinamica vengono eseguiti;
• trasferimento dati: byte serviti dalla rete e scambi con origini esterne, anche quando il database è altrove;
• immagini: trasformazioni, letture e scritture della cache e consegna via CDN;
• osservabilità: eventi, retention, query e integrazioni necessarie a diagnosticare la produzione.

Cache e rendering statico possono ridurre il compute, mentre una pagina dinamica molto visitata o una funzione che attende API lente possono moltiplicarlo. Anche l’architettura geografica conta: spostare molti dati tra funzione e database in regioni diverse aggiunge latenza e può produrre egress su uno o entrambi i lati.

Le metriche da modellare su Supabase

• compute per progetto: ogni progetto gestito ha la propria istanza Postgres e il consumo cresce con dimensione e ore attive;
• egress: traffico in uscita da database, Auth, Storage, Edge Functions, Realtime e log drain;
• storage e disco: dati, oggetti, crescita, prestazioni e trasformazioni delle immagini;
• utenti attivi: MAU, utenti SSO o di terze parti e funzioni di autenticazione aggiuntive;
• Realtime: messaggi e picco delle connessioni, che dipendono dal comportamento dell’app e non solo dal numero di utenti;
• continuità e letture: PITR, repliche, compute delle repliche e capacità aggiuntiva;
• log: ingestione, query, retention e invio verso sistemi esterni.

Ambienti di staging, preview e branch sono parte del costo se restano attivi. La domanda è quindi quanto costa l’intera catena per un utente o una transazione nelle condizioni normali, di picco e di abuso. Budget e avvisi devono essere configurati prima del traffico; uno spend cap non copre necessariamente ogni add-on o risorsa.

Portabilità: Postgres aiuta, ma non basta un export

Supabase usa Postgres e pubblica molti componenti come open source. Questo riduce una parte del lock-in: tabelle e query standard sono più portabili di un database proprietario. Self-hosting è possibile. Non significa però che una migrazione dell’applicazione coincida con pg_dump.

L’app può dipendere da Row Level Security, estensioni, funzioni SQL, API PostgREST, trigger Realtime e convenzioni del client. Auth include utenti, provider OAuth, email, sessioni, chiavi e JWT: cambiare issuer o chiavi può invalidare sessioni e richiede un piano di transizione. Storage comprende oggetti, metadati, policy e URL. Edge Functions, variabili, job e integrazioni vanno ridistribuiti. La guida ufficiale per ripristinare un progetto gestito in self-hosting precisa, per esempio, che il trasferimento degli oggetti Storage e il redeploy delle Edge Functions non sono coperti dal solo ripristino del database.

Anche Vercel crea dipendenze se l’app usa runtime, routing, middleware, immagini, cron, cache, analytics o servizi proprietari. Un framework portabile non rende automaticamente portabile la configurazione che lo circonda. Il test utile è distribuire periodicamente una versione minima su un ambiente alternativo e misurare ciò che manca.

GDPR: la regione del workload è solo una riga della verifica

Scegliere una regione europea per funzioni e database è una buona misura di localizzazione e latenza. Non consente però di affermare che «tutti i dati sono sicuramente in Europa». Bisogna distinguere almeno:

• i dati applicativi nel workload e nei backup;
• il control plane usato per amministrare account, progetti e deploy;
• log, telemetria, analytics e dati generati dal servizio;
• ticket e contenuti condivisi con il supporto;
• sub-responsabili e luoghi dai quali può avvenire il trattamento o l’accesso.

La documentazione delle regioni Supabase dice dove viene distribuito il progetto primario; il DPA disciplina in modo più ampio dove Supabase e i sub-responsabili possono trattare i dati e come opera una regione richiesta. Il DPA Vercel distingue inoltre i customer data dai service-generated data e rimanda alla lista aggiornata dei sub-responsabili. Le formulazioni contrattuali, il piano acquistato e i servizi abilitati devono essere letti insieme, non dedotti dalla posizione del database.

Prima del go-live occorre verificare il DPA applicabile, ruoli e istruzioni, categorie di dati, localizzazione di ogni trattamento, lista e modifiche dei sub-responsabili, accessi amministrativi, cifratura, retention, restituzione e cancellazione. Per eventuali trasferimenti fuori dallo Spazio economico europeo vanno identificati il meccanismo giuridico, le SCC quando pertinenti, la valutazione del trasferimento e le misure supplementari. La guida EDPB per le PMI ricorda espressamente la necessità di documentare circostanze, legislazione del paese di destinazione e salvaguardie. Questa è una verifica tecnico-organizzativa da completare con il proprio consulente privacy: la selezione di una regione non è una dichiarazione automatica di conformità.

Lo SLA non è un piano di continuità

Uno SLA copre un servizio definito, applica esclusioni e normalmente riconosce crediti quando il livello non viene rispettato. Lo SLA Enterprise di Vercel, per esempio, delimita i servizi coperti, esclude gli eventi qualificati come downtime giustificato e prevede crediti. Non promette che database, autenticazione, DNS, email e fornitori esterni della tua applicazione funzionino insieme.

Il credito può compensare una parte della fattura; non recupera ordini persi, non ricostruisce dati e non risponde ai clienti. Per questo RTO, RPO, responsabilità e procedure di comunicazione restano requisiti dell’azienda anche quando ogni fornitore rispetta il proprio contratto.

“Multi-region” non descrive tutta l’applicazione

Una CDN distribuita globalmente può continuare a servire asset statici mentre le funzioni dinamiche o il database primario sono indisponibili. Una read replica può assorbire letture e aiutare in alcuni scenari, ma è in sola lettura: non rende automaticamente disponibili login, scritture o Storage e può presentare ritardo di replica. Un failover del database non sposta da solo funzioni, segreti, code, webhook o servizi email.

La mappa di continuità deve separare CDN e DNS, funzioni, database primario, repliche, Auth, Storage, Realtime e fornitori esterni. Per ogni elemento servono modalità di guasto, dipendenze, comportamento degradato e procedura di recupero. La checklist di produzione Supabase suggerisce esplicitamente di valutare backup, PITR, repliche e SMTP proprio perché sono controlli distinti.

Checklist di produzione

• stimare consumi normali, picchi e abusi per progetto e servizio, con data e assunzioni;
• configurare budget, avvisi e un responsabile che controlli fattura e unit economics;
• allineare regioni di funzioni e dati e misurare latenza ed egress tra piattaforme;
• inventariare dati personali in workload, log, supporto e control plane;
• verificare DPA, sub-responsabili, trasferimenti, SCC, accessi, retention e cancellazione;
• definire RTO e RPO, configurare backup/PITR dove richiesto e provare il ripristino;
• testare autorizzazioni server-side, RLS, rotazione chiavi, limiti e percorsi di abuso;
• monitorare separatamente frontend, funzioni, database, Auth, Storage e servizi esterni;
• documentare incident response, degrado controllato e comunicazione agli utenti.

Un piano d’uscita verificabile

• esportare periodicamente schema, dati e oggetti in formati utilizzabili e provarne il restore;
• inventariare funzioni proprietarie e indicare per ciascuna un’alternativa o il costo di riscrittura;
• conservare Infrastructure as Code, variabili documentate e procedure di deploy fuori dal solo control plane;
• provare la migrazione di Auth, inclusi utenti, provider, email, JWT e sessioni attive;
• eseguire un deployment minimo su un secondo ambiente e misurare tempi, differenze e competenze necessarie;
• definire soglie economiche, contrattuali o tecniche che fanno scattare la decisione di uscita.

La portabilità non richiede evitare ogni servizio gestito: richiede sapere che cosa si sta delegando e mantenere una via d’uscita proporzionata al rischio. Se un prototipo su queste piattaforme deve diventare un sistema aziendale, la pagina Codice in loop descrive come analizzare dipendenze, costi e recuperabilità prima che la piattaforma diventi una scelta irreversibile.