Dietro le quinte con Lakebase, parte 2

In parte 1 di questa serie, abbiamo esplorato come spostare il database sottostante di Backstage su Databricks Lakebase ha trasformato migrazioni di schema rischiose in operazioni di branch e test di 1 secondo. Ma un ciclo di sviluppo più rapido ti porta solo fino a un certo punto se i team di Sicurezza e Governance trattano ancora il tuo database operativo come una scatola nera.

In uno stack tradizionale, il tuo database applicativo e il tuo data lake vivono in due paradigmi di sicurezza completamente diversi. Il grafo di proprietà della tua infrastruttura vive in Backstage, supportato da un'istanza RDS isolata e governato da complessi ruoli IAM e grant nativi di Postgres. Nel frattempo, i dati del tuo warehouse sono governati dal team di dati utilizzando Unity Catalog. Unity Catalog è un framework Open Source creato da Databricks che fornisce un livello di governance unificato per dati, AI e ora database operativi – un unico posto per gestire controlli di accesso, audit trail, lineage e conformità su tutto ciò che è presente sulla piattaforma.

Per controllare un singolo drop di tabella su RDS, dovresti incrociare CloudTrail per il principal IAM, pg_stat_activity o pgaudit log per l'istruzione SQL e CloudWatch per il timestamp, tre servizi, tre linguaggi di query, tre policy di accesso. Il database operativo diventa un canale secondario di conformità.

Unity Catalog Assorbe il Database Operativo

Quando abbiamo puntato Backstage su Lakebase, non abbiamo solo cambiato dove risiedevano i dati; abbiamo cambiato dove risiedeva la policy di accesso.

Poiché Lakebase è nativamente integrato in Databricks, Unity Catalog si estende direttamente sul database Postgres operativo. In questo POC, abbiamo utilizzato Lakehouse Federation per esporre il catalogo Backstage come catalogo esterno (lakebase_bs) in Unity Catalog. Una volta lì, i grant UC standard controllano chi può vedere cosa, senza necessità di gestione dei ruoli a livello di Postgres:

Sebbene non abbiamo costruito policy di Row-Level Security end-to-end per Backstage in questo POC, architetturalmente, le stesse identiche regole RLS che proteggono le tabelle di fatturazione sensibili possono essere applicate direttamente a queste tabelle operative. Il muro tra "operativo" e "analitico" smette di essere un confine fisico e diventa semplicemente un pattern di accesso.

Un Audit Trail Unificato Out of the Box

Ricordi il branching copy-on-write di 1 secondo che abbiamo eseguito nella Parte 1? In una configurazione tradizionale, dimostrare a un ingegnere della sicurezza che uno sviluppatore ha solo clonato il database per un'ora e poi l'ha distrutto è un esercizio manuale.

Con Lakebase, ogni azione del control plane contro il database operativo viene registrata automaticamente in system.access.audit. Per dimostrarlo, abbiamo interrogato il log di audit per le esatte operazioni di branch dei nostri esperimenti di disaster recovery della Parte 1:

Risultato:

Ogni creazione e cancellazione di branch dai nostri esperimenti della Parte 1 è registrata. Ogni evento è collegato a una specifica identità utente OAuth e IP sorgente, catturato automaticamente e governato dagli stessi identici controlli di Row-Level Security di ogni altra tabella di audit in Unity Catalog. Nessun incrocio di CloudTrail. Nessun parsing di log RDS. Una query SQL.

Attribuzione Costi Automatica per Branch

Un team di governance non vuole solo sapere chi ha creato un branch, ma vuole sapere quanto è costato.

In un ambiente AWS tradizionale, tracciare il costo di un'istanza RDS effimera richiede strategie di tagging CloudWatch personalizzate che spesso perdono i workload di breve durata. Poiché Lakebase si integra nativamente con le tabelle di fatturazione di sistema di Unity Catalog, i costi di calcolo vengono suddivisi automaticamente per project_id, branch_id e endpoint_id.

In questo POC, il branch di produzione è stato fatturato a 31.6130 DBU, mentre il branch di test eliminato è stato attribuito in modo indipendente 0.0107 DBU. L'audit trail e il cost trail sono governati nello stesso identico posto.

Cosa Significa Questo per i Team Che Fanno Branch Ogni Giorno

La nostra storia di governance risponde alla domanda di conformità: possiamo dimostrare chi ha fatto cosa, quando e quanto è costato? La risposta è sì – una query SQL invece di tre servizi. Ma c'è una seconda domanda di governance che conta altrettanto per i team di sviluppo che adottano il workflow di branching della Parte 1: cosa succede alla governance quando il tuo team crea dozzine di branch per sprint?

Nella Parte 1, abbiamo descritto un workflow in cui ogni branch di funzionalità e ogni pull request ottiene la propria copia di database isolata. Un team di sei sviluppatori che esegue sprint di due settimane potrebbe creare e distruggere 30-40 branch in un singolo sprint. Si tratta di 30-40 copie di dati di produzione, ognuna delle quali potrebbe contenere campi sensibili – PII del cliente, record finanziari, dati sanitari.

È qui che la governance a livello di branch di Unity Catalog diventa portante, non solo conveniente. Quando viene creato un branch Lakebase, le policy di mascheramento a livello di attributo di Unity Catalog si propagano automaticamente al nuovo branch. Uno sviluppatore che lavora sul proprio branch di funzionalità non vede mai dati di produzione non mascherati – non perché qualcuno si sia ricordato di configurarlo, ma perché il livello di governance lo impone al momento della creazione. Il branch CI che esegue i test delle PR è governato in modo identico alla produzione. Il branch QA in cui un tester esegue scenari distruttivi è governato in modo identico alla produzione. Non esiste un "eccezione non di produzione" in cui dati sensibili trapelano perché qualcuno ha dimenticato di applicare la policy.

Questo è più importante di quanto sembri. Secondo il report 2025 State of Data Compliance di Perforce, il 60% delle organizzazioni ha subito violazioni o furti in ambienti non di produzione in cui dati sensibili erano inadeguatamente anonimizzati. L'approccio tradizionale – mascherare manualmente i dati durante il provisioning di ambienti dev/test – non scala quando gli ambienti vengono creati e distrutti in pochi secondi. La governance deve essere automatica, altrimenti non avviene.

La Nuova Opportunità del DBA

L'audit trail e i dati di attribuzione dei costi segnalano anche un cambiamento più silenzioso: il ruolo del DBA si sta evolvendo dal lavoro reattivo su ticket all'architettura strategica della piattaforma.

Oggi, gran parte del tempo di un DBA è dedicato alle richieste operative: provisioning dell'ambiente, revisioni dello schema, aggiornamenti dei dati, concessioni di accesso. Un team di sei sviluppatori può generare oltre 30 ticket per sprint, e il calendario del DBA diventa una coda. L'esperienza che rende preziosi i DBA – la comprensione dell'integrità dei dati, delle prestazioni e della governance a un livello profondo – viene sepolta sotto un lavoro di provisioning ripetitivo.

Quando il branching è self-service e la governance è automatica, quel lavoro ripetitivo scompare. Gli sviluppatori provisionano i propri ambienti in un secondo. Le modifiche allo schema vengono riviste in modo asincrono nelle pull request – il DBA vede un diff dello schema formattato pubblicato dalla CI, lo rivede secondo la propria pianificazione e approva o richiede modifiche attraverso il normale flusso di lavoro delle PR. Con il tempo ora disponibile, queste revisioni diventano più approfondite: il DBA aiuta i membri del team a comprendere i dati e le strutture esistenti in produzione, lavora con loro per arrivare a soluzioni migliori ed esegue revisioni approfondite che mantengono gli standard di integrità dei dati e di governance. Il mascheramento dei dati viene applicato per policy, non per intervento manuale. L'attribuzione dei costi è automatica, non un esercizio di riconciliazione mensile.

Ciò che si apre è il lavoro che sfrutta realmente l'esperienza del DBA: definire le policy di branching, progettare le regole di governance, architettare i flussi di lavoro di promozione, ottimizzare le prestazioni e stabilire le linee guida che rendono sicuro il self-service. Il DBA passa dal fare il lavoro al progettare come il lavoro viene svolto – da oltre 30 ticket operativi per sprint a meno di 5 revisioni di policy ad alto valore. Il trail di audit dimostrato sopra non è solo un artefatto di conformità – è il nuovo dashboard strategico del DBA, una visione in tempo reale di come viene utilizzata la piattaforma e dove investire in seguito.

Dal cambio di ruolo agli strumenti

Il passaggio del DBA dai ticket operativi alla progettazione della piattaforma funziona solo se gli strumenti cambiano con il ruolo. La piattaforma deve svolgere il lavoro di routine da sola, e il DBA ha bisogno di un posto per progettare come viene svolto quel lavoro.

Due strumenti open-source, entrambi distribuiti come Databricks Apps e entrambi governati dalle stesse concessioni di Unity Catalog e dal trail di audit descritti sopra, chiudono questo ciclo.

LakebaseOps è ciò che la piattaforma fa da sola. Tre agenti – Provisioning, Performance e Health – sostituiscono 51 dei compiti per i quali un DBA presentava ticket. Sette di essi vengono eseguiti come Databricks Jobs pianificati e sostituiscono il crontab pg_cron che un DBA manterrebbe manualmente. Un'interfaccia utente di monitoraggio mostra metriche pg_stat live, regressioni di query lente, applicazione della TTL dei branch e un dashboard di adozione con 9 KPI. Una procedura guidata di migrazione valuta dieci motori sorgente (Aurora, RDS, Cloud SQL, AlloyDB, Cosmos DB e altri) rispetto a Lakebase, con prezzi live dalle API AWS e Azure.

Lakebase MCP è ciò che il DBA fa sopra la piattaforma. Un server Model Context Protocol espone 46 strumenti a qualsiasi agente AI compatibile con MCP (Claude, Copilot, GPT). Il DBA smette di aprire pgAdmin e inizia a descrivere l'intento:

Due scelte di progettazione mantengono la sicurezza. Primo, governance a doppio livello: una guardia per le istruzioni SQL e una guardia di accesso per strumento, con quattro profili predefiniti (read_only, analyst, developer, admin) che si mappano sugli stessi pattern di accesso UC mostrati sopra. Un assistente di codifica viene eseguito come read_only e fisicamente non può eliminare una tabella.

Secondo, ogni query è attribuibile – il server tagga ogni istruzione con lo strumento di origine:

Combinato con l'attribuzione dei costi a livello di branch mostrata in precedenza, è possibile rispondere "quale agente su quale branch ha generato il picco di CPU delle 4 del mattino?" in una singola query SQL.

LakebaseOps viene eseguito per il team. Lakebase MCP viene eseguito con il team. Entrambi ereditano la postura di governance che avete appena visto.

Nella Parte 3 di questa serie, esamineremo il vantaggio finale: unire i dati di proprietà dell'infrastruttura all'interno di Backstage direttamente ai dati di fatturazione cloud in un'unica query SQL.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale