Firebird memorizza e gestisce tutto il metadata per sé stesso e per gli oggetti definiti dall'utente in speciali tabelle dette tabelle di sistema o system tables, sempre nel database stesso. Gli idetificatori per queste tabelle di sistema, le loro colonne e altri tipi di oggetti di sistema iniziano tutti con i caratteri RDB$.

Poichè sono comunque degli oggetti ordinari della base di dati, possono essere interrogati (fin qui poco male) e manipolati (qui no) come altri oggetti definiti dall'utente. Tuttavia, il fatto che si può non significa che si debba farlo. Il motore di Firebird implemente un insieme ad alto livello dell'SQL(DDL) allo scopo di definire ed operare sugli oggetti del metadata, tipicamente attraverso i comandi CREATE, ALTER e DROP.

Va raccomandato fortemente di usare operazioni DDL (non quelle SQL direttamente sulle tabelle di sistema) ogni qualvolta ci sia necessità di modificare il metadata. Meglio ritardare le operazioni dirette fino a quando l'esperienza in SQL e la conoscenza del motore Firebird non siano diventate veramente avanzate. Una base dati rovinata non è granchè utile, nè facile da riparare.

L'installazione tipica di Firebird abilita per default la scrittura forzata, le c.d. «forced writes» (o anche synchronous writes cioè scritture sincrone). Significa che le modifiche ai dati e gli inserimenti sono scritti immediatamente al momento stesso della conferma del dato (nota: al momento del POST del dato, non al momento del COMMIT della transazione che è successivo).

È possibile assegnare ad un database la possibilità di utilizzare scritture dei dati asincrone, in cui i dati modificati o nuovi sono tenuti in memoria e solo periodicamente scritti su disco attraverso la gestione di I/O del sistema operativo. Di solito si attribuisce a questa configurazione il nome di forced writes off (o anche disabled). Viene talvolta utilizzato per migliorare le prestazioni temporaneamente durante lunghe operazioni di inserimento massiccio di dati.

Qui va fatta un'avvertenza grossa come una casa: bisogna assolutamente non disabilitare le «forced writes» su un server Windows. È stato osservato più volte che sulla piattaforma Windows la memoria tampone del disco non viene scaricata completamente fino a quando non viene completamente fermato il servizio Firebird. Oltre ai problemi di alimentazione, potrebbero esserci altri problemi su un server Windows. Se si blocca per un qualsiasi motivo, il sistema di I/O è fuori controllo ed il lavoro in corso degli utenti verrebbe perso facendo ripartire il sistema.

Una delle opzioni del programma di utilità gbak facendo il restore (gbak -rep[lace_database]) permette di recuperare una copia sopra una base di dati esistente. È possibile farlo senza nessun avviso del fatto che ci siano utenti collegati e quindi il database sia in uso: in questo caso la distruzione del database è quasi certa.

Se è possibile, sarebbe meglio fare il restore su uno spazio disco alternativo usando gbak -c[reate] e verificare il database appena creato usando isql o un altro strumento di amministrazione di proprio gradimento. Se il database è buono, allora fermare il server, copiare altrove il vecchio database e copiare il nuovo database sul vecchio.

Se non si impedisce agli utenti di accedere durante il restore fatto con gbak -rep[lace_database], questi potrebbero effettuare operazioni sui dati. Il database in questo caso verrebbe danneggiato severamente.