- Supabase usa PostgreSQL come motore di database, non un database “proprietario”.
- Quindi è un database relazionale SQL al 100%.
- Non è “un mix” come Firebase o FaunaDB: niente document store, niente NoSQL — è SQL classico con estensioni potenti (PostGIS, funzioni serverless, etc.).
Sia MariaDB che PostgreSQL sono database relazionali, ma hanno differenze importanti che influiscono sul modo in cui scrivi codice e strutturi i dati. Le macro differenze:
| Aspetto | MariaDB (MySQL) | PostgreSQL (usato da Supabase) | Impatto sul codice |
|---|---|---|---|
| Standard SQL | Più permissivo, a volte non standard | Più aderente agli standard SQL | Query più “pure” e portabili in PostgreSQL |
| Tipi di dato | Più limitati (no JSON avanzato, array nativi) | Molto ricco: JSONB, ARRAY, UUID, ENUM, HSTORE |
Puoi lavorare con strutture più complesse direttamente in SQL |
| Funzioni | Funzioni limitate, stored procedure classiche | Funzioni avanzate, scrivibili in PL/pgSQL e anche in altri linguaggi | Logica lato DB molto più potente e modulare |
| Estensioni | Poche | Tante (es. PostGIS per dati geografici, pgcrypto per hashing, ecc.) | Funzioni specializzate già pronte senza scriverle in app |
| Gestione relazioni | Solida ma basica | Molto robusta, con FOREIGN KEY più flessibili, ON DELETE CASCADE, trigger, DEFERRABLE CONSTRAINTS |
Miglior controllo dell’integrità referenziale |
| Query JSON | Limitato (JSON ma niente indicizzazione evoluta) |
JSONB con indicizzazione GIN, query complesse |
Mescolare dati semi-strutturati e relazionali in modo pulito |
| CTE e Window Functions | Supporto base | Supporto molto avanzato | Query analitiche direttamente in SQL senza doverle fare nell’app |
| Gestione concorrente | Locking semplificato | MVCC (multi-version concurrency control) molto robusto | Meno problemi di deadlock, migliori transazioni parallele |
-
Query più ricche In PostgreSQL puoi fare molto più lavoro direttamente lato SQL, invece di delegare tutto alla logica del backend. Es. aggregazioni, filtri complessi, ricerche full-text, join su JSON, query ricorsive.
-
Strutture dati avanzate Puoi usare array e JSON direttamente nelle colonne senza snaturare il modello relazionale. In MariaDB/MySQL di solito devi fare hack tipo serializzare dati o creare tabelle extra.
-
Stored Functions e Trigger potenti Puoi scrivere logica complessa dentro il DB, che in Supabase viene spesso usata insieme a Row Level Security (RLS) per gestire permessi a livello di riga in automatico, senza passare tutto dal backend.
-
Autenticazione e permessi integrati (Supabase specifico) Supabase sfrutta PostgreSQL + policy di sicurezza per far sì che tu possa interagire direttamente con il DB da frontend in sicurezza, cosa che con MariaDB normalmente non fai mai — ti serve un backend intermedio.
💡 In sintesi:
- A livello concettuale, sempre SQL relazionale.
- A livello pratico, con PostgreSQL (e quindi Supabase) puoi usare funzionalità più moderne, ridurre parte della logica lato backend, e lavorare con dati relazionali + semi-strutturati in modo nativo e più pulito.
- Se il tuo codice era scritto pensando a MariaDB, 9 query su 10 funzioneranno anche in PostgreSQL, ma funzioni specifiche, tipi di dato e sintassi per certe operazioni possono differire.