Pagina 2 di 3
Il database è quasi sempre il primo posto dove un'applicazione rallenta, e quasi sempre l'ultimo che qualcuno guarda. La maggior parte dei problemi di performance che ho visto in vent'anni non erano nel codice PHP: erano in una query senza indice, in uno schema pensato male o in un accesso ai dati che nessuno aveva mai profilato. In questa categoria il database torna al centro, dove merita di stare.
Il primo tema è la performance come questione di dati. Tuning e diagnosi delle query lente, indici usati con criterio, UUID v7 come chiave primaria per non distruggere le prestazioni di InnoDB, caching a più livelli quando ha senso. Il filo conduttore è sempre lo stesso: prima si misura dove sta davvero il collo di bottiglia, poi si interviene, e quasi sempre il guadagno arriva senza comprare un server più grande.
Il secondo tema è l'integrità e la continuità. Un database veloce ma che perde dati o che non si può ripristinare non serve a niente: backup che reggono davvero, dall'incrementale al dump senza lock, e migrazioni delicate come lo spostamento di una versione a fine vita senza fermare il business. Qui la posta in gioco non è la velocità, è la fiducia che i dati ci siano ancora domani.
Il terzo tema è la scala e il nuovo carico: sharding quando i record diventano milioni, la scelta ragionata fra MySQL e PostgreSQL, e il database che inizia a servire anche l'AI, con pgvector che trasforma PostgreSQL in un motore vettoriale senza aggiungere infrastruttura.
Se hai un database lento o uno schema da rivedere, vedi la consulenza IT e DevOps o scrivimi.
Il database non è un dettaglio implementativo. È il posto dove le scelte sbagliate diventano lente e costose.
Ho costruito tre SaaS multi-tenant in Laravel negli ultimi tre anni con approcci diversi: database per tenant (massimo isolamento, costo elevato), schema per tenant (buon compromesso), colonna tenant_id (semplice, rischio di data leak tra tenant). Vi racconto i trade-off reali e quando ho cambiato idea. Continua a leggere
Un'API pubblica Laravel per la verifica dei codici fiscali veniva martellata da scraper: 4.000 richieste al minuto da IP singoli. Il throttle di default di Laravel non bastava. Ho implementato un sistema multi-livello: rate limit per IP, per chiave API, per endpoint e un adaptive rate limiter che scala in base al carico. Continua a leggere
Un catalogo prodotti da 200.000 articoli con ricerca MySQL LIKE a 8 secondi. Ho integrato Elasticsearch 8 con Laravel tramite il pacchetto Scout, definito il mapping per il dominio specifico e costruito la sincronizzazione incrementale. La ricerca è scesa a 40ms, con rilevanza di risultati nettamente superiore. Continua a leggere
Ho migrato due applicazioni Laravel da MySQL a PostgreSQL negli ultimi 18 mesi. I motivi: JSONB nativo per dati semi-strutturati, full-text search senza Elasticsearch, e le transazioni ACID più robuste per sistemi finanziari. Vi racconto le differenze pratiche che si sentono nel codice quotidiano. Continua a leggere
Ho usato Laravel Telescope su un'applicazione di e-commerce per analizzare 48 ore di traffico reale. I risultati erano impietosi: 340 query per pagina di listing, di cui 280 erano N+1 generati da relazioni non ottimizzate. Vi mostro i 10 pattern più comuni e come identificarli prima che arrivino in produzione. Continua a leggere
Una piattaforma SaaS con 8 milioni di record nella tabella principale aveva query a 4 secondi nonostante tutti gli indici corretti. L'analisi ha mostrato che il problema non era l'indicizzazione ma il volume. Vi racconto l'approccio di sharding che abbiamo implementato con Laravel e come abbiamo gestito la migrazione live. Continua a leggere
Molti usano Redis in Laravel solo come cache di secondo livello. Su un'applicazione di prenotazioni con picchi di 500 richieste al secondo, ho sfruttato Redis Sorted Sets per la gestione delle priority queue, Pub/Sub per le notifiche real-time e un layer di session management con persistenza distribuita. Continua a leggere
Un gestionale Laravel su Hetzner con MySQL che impiegava 3-4 secondi per ogni query di ricerca prodotti. La causa: InnoDB buffer pool a 128MB su un database da 6GB, reverse DNS lookup attivo e 47 query senza indice per ogni pagina catalogo. Diagnosi con slow query log, EXPLAIN e MySQLTuner, fix in due ore. Continua a leggere
Su un VPS Hetzner AX41 con un e-commerce Laravel, MySQL 8.0 era raggiungibile da internet sulla porta 3306, l'utente root non aveva password, e l'applicazione usava root per tutte le operazioni - dal checkout alle migration. L'audit ha rivelato 14 violazioni del CIS Benchmark. Il protocollo di hardening che applico in due ore: mysql_secure_installation, segregazione utenti, bind su localhost, TLS obbligatorio, disabilitazione local_infile e audit log. Continua a leggere
Un VPS Hetzner con Redis 6 esposto su 0.0.0.0:6379 senza password. Un attaccante ha usato il motore Lua integrato per scrivere un crontab che scaricava un cryptominer Monero. CPU al 100%, Laravel a 12 secondi di response time, e nessuno sapeva perché. Il caso reale di un SaaS piemontese del luglio 2025, la diagnosi in 40 minuti, l'eradicazione e l'hardening di Redis per impedire che succeda di nuovo. Continua a leggere
Tool gratuiti per il tuo lavoro sui dati:
