Lovable e Bolt costruiscono il frontend in pochi minuti — ma un’app che non ricorda nulla tra una sessione e l’altra non è un’app, è un prototipo. Supabase è il layer che trasforma il prototipo in un prodotto reale: database PostgreSQL managed, autenticazione con decine di provider, storage per file e immagini, Row Level Security per la protezione dei dati. Tutto gratuito fino a 500 MB di database e 50.000 utenti attivi al mese. Nona puntata del percorso Stack Digitale 2026.
C’è un momento preciso in cui il vibe coding smette di essere un gioco e diventa un progetto vero. Di solito coincide con la prima domanda: “ma i dati dove li salvo?”. Lovable genera un’interfaccia React bellissima. Bolt costruisce un’app funzionante con autenticazione e filtri. Ma senza un backend, ogni refresh azzerà tutto — nessun utente registrato, nessun dato persistente, nessuna sessione salvata.
Supabase è la risposta a quella domanda. E — dettaglio non secondario — è open source, self-hostabile e ha un piano gratuito che per la grande maggioranza dei progetti personali e delle MVP non si esaurisce mai.
Cos’è Supabase: il backend che non devi programmare
Supabase è spesso descritto come “Firebase open source”. La definizione è comoda ma riduttiva. Firebase è un ecosistema proprietario Google con database NoSQL (Firestore). Supabase usa PostgreSQL — il database relazionale più diffuso al mondo — e lo espone tramite API REST e GraphQL autogenerate. Se sai scrivere una query SQL di base, sai già usare Supabase. Se non la sai scrivere, l’editor visuale delle tabelle copre il 90% dei casi d’uso senza toccare una riga di codice.
La dashboard qui sotto è quella di un progetto reale — “demo-flowygo” — creato in un account Supabase su piano Free. Nello status panel si vede l’intera stack di servizi attivi e in salute: Database, PostgREST (le API automatiche), Auth, Realtime, Storage, Edge Functions. Sei servizi backend, tutti operativi, tutti gestiti, senza aver scritto una riga di configurazione server. Regione: West EU (Ireland) — server in Europa, rilevante per il GDPR.
Integrazione con i tool di vibe coding: Bolt e Lovable
Entrambi i tool principali di vibe coding integrano Supabase nativamente — ma con approcci diversi che vale la pena capire prima di iniziare un progetto.
Bolt: connessione al tuo account Supabase esistente
Bolt è il tool che offre più controllo sull’integrazione. Di default crea un database gestito internamente, ma dalla sezione Project Settings → Database → Advanced puoi collegare un progetto Supabase esistente del tuo account. La schermata qui sotto mostra esattamente questa opzione: “Connect to an existing database — Connect to a different Supabase project to manage your data”. Il pulsante Connect apre un modal che chiede l’URL del progetto e la chiave API — entrambi disponibili in Supabase sotto Project Settings → API.
Il warning arancione che vedi è onesto e importante: collegare un database Supabase esterno a un progetto Bolt già esistente può causare disallineamenti tra il codice generato e lo schema del database nuovo. La pratica corretta è collegare Supabase prima di iniziare a costruire — non dopo. In quel caso il codice generato da Bolt si scrive già sapendo qual è il database di destinazione.
Lovable: Supabase integrato ma gestito separatamente
Lovable funziona in modo diverso: quando generi un’app con funzionalità di autenticazione o database, crea automaticamente un’istanza Supabase dedicata al progetto — accessibile dal pannello interno di Lovable ma non visibile direttamente nell’account Supabase personale dell’utente. È un approccio più semplice (zero configurazione), ma meno trasparente: non hai accesso diretto alle tabelle, alle policy RLS o all’editor SQL tramite il dashboard Supabase standard.
La buona notizia è che Lovable espone comunque un pannello Supabase interno con Table Editor, SQL Editor e visualizzazione delle policy — funzionalmente equivalente, anche se non è il tuo account. Per la grande maggioranza dei progetti this-is-fine. Se hai bisogno di accesso completo al database Supabase con il tuo account (per esempio per collegarlo a Grafana, per exportare i dati verso altri sistemi, o per usare la Row Level Security avanzata), la strada è usare Bolt con connessione al tuo Supabase personale, come mostrato nello screenshot precedente.
Cosa viene costruito in pratica: la todo app di Bolt con Supabase Auth
Lo screenshot qui sotto è il risultato di un prompt inviato a Bolt: “Crea un’app todo con autenticazione utente via Supabase Auth — login con email e password, gestione task con priorità e data di scadenza, dashboard con contatori totale/attivo/completato”. Tempo di generazione: circa 90 secondi.
L’app si chiama Taskflow. In alto a destra si vede l’email dell’utente loggato ([email protected]) con il pulsante Sign Out — l’autenticazione è reale, gestita da Supabase Auth. I tre card in alto mostrano i contatori: 1 Total, 1 Active, 0 Done. Il task in lista — “Project design”, priorità medium, scadenza 21 maggio — è persistito nel database Supabase: se si chiude e riapre il browser, è ancora lì. Nel pannello sinistro il codice generato da Bolt descrive esplicitamente la scelta tecnica: autenticazione via Supabase Auth con React context, form login/register con tab switching.
Row Level Security: la funzione che separa un prototipo da un prodotto sicuro
Questo è il concetto più importante dell’articolo — e probabilmente quello meno intuitivo per chi viene dal mondo no-code. Quando Bolt o Lovable generano un’app con database Supabase, le tabelle vengono create con la Row Level Security (RLS) abilitata per default. Ma cosa significa in pratica?
Senza RLS, chiunque conosca l’URL del tuo progetto Supabase e la chiave API pubblica può leggere tutti i dati di tutti gli utenti. Con RLS attiva, ogni utente può accedere solo alle proprie righe — quelle dove la colonna user_id corrisponde all’ID dell’utente autenticato. La verifica avviene lato database, non lato applicazione: non importa se il frontend ha un bug, il database non restituisce mai dati di altri utenti.
Le quattro policy che Bolt genera automaticamente
Lo screenshot qui sotto mostra il pannello Authentication → Policies del progetto Supabase collegato a Bolt, filtrato sulla tabella todos. Quattro policy generate automaticamente dall’AI, una per ogni operazione CRUD:
- Users can delete own todos — comando DELETE — applicato a: authenticated
- Users can insert own todos — comando INSERT — applicato a: authenticated
- Users can update own todos — comando UPDATE — applicato a: authenticated
- Users can view own todos — comando SELECT — applicato a: authenticated
Tutte e quattro applicano la stessa logica di base: l’operazione è consentita solo se l’utente è autenticato e il user_id della riga corrisponde all’ID della sessione corrente. Il banner in alto segnala anche la possibilità di auto-abilitare RLS su tutte le nuove tabelle — una best practice che Bolt attiva di default. Il pulsante Create policy permette di aggiungere regole personalizzate in SQL per casi più complessi: per esempio, permettere la lettura pubblica di alcune righe ma la modifica solo al proprietario.
Piano Free vs piani a pagamento: quando Supabase è davvero gratuito
Il piano Free di Supabase include: 500 MB di database PostgreSQL, 1 GB di storage file, 50.000 utenti attivi al mese per l’autenticazione, 500.000 invocazioni di Edge Functions al mese, 2 GB di banda in uscita. Per una MVP, un progetto personale o un tool interno aziendale con poche decine di utenti attivi, il piano gratuito non si esaurisce mai nella pratica.
I limiti da tenere presenti: le istanze free vengono messe in pausa dopo 7 giorni di inattività (il primo accesso dopo la pausa le riattiva automaticamente in circa 30 secondi). Il compute è NANO — sufficiente per sviluppo e piccoli volumi, non per applicazioni con centinaia di query simultanee. Per quei casi il piano Pro parte da 25 dollari al mese con compute dedicato e nessuna pausa automatica.
Supabase vs Firebase: la bussola rapida
Firebase è la scelta giusta se il tuo stack è interamente Google (Google Auth, Firestore, Firebase Hosting, Analytics) e preferisci database NoSQL document-oriented. Supabase è la scelta migliore se hai bisogno di relazioni tra tabelle, query SQL complesse, esportazione dati standard, open source con possibilità di self-hosting, o se la GDPR è una priorità e vuoi server in Europa. Per i tool di vibe coding — Bolt, Lovable, Cursor — Supabase è diventato lo standard de facto proprio perché PostgreSQL è il database che i modelli AI conoscono meglio e generano in modo più affidabile.
Prossima puntata: Apache Kafka Parte 1
Con Supabase chiudiamo il blocco delle applicazioni: Forms per raccogliere dati, Sheets per analizzarli, Neo4j per le relazioni, Claude Code e Design per costruire il prodotto, Grafana per il monitoring, RAG per i chatbot aziendali, AI multimodale per i documenti, Sentiment Analysis per il testo, Supabase per il backend. La settimana prossima entriamo nel data engineering avanzato: Apache Kafka, il sistema nervoso distribuito di Netflix, LinkedIn e Uber. Come funzionano topic, partizioni e consumer group — e perché non è “solo un message broker”. Supabase per app vibe-coded: il backend che trasforma un prototipo in un prodotto. Il passo successivo è gestire i dati a scala.
