L'atomicité garanti qu'il n'y a que deux résultats possibles pour une tâche (que l'on nomme transaction) qui implique des changements de multiples ensembles de données interdépendants : soit toutes les étapes ont été réalisées correctement et le résultat peut être validé dans la base comme une seule entité ou, si l'une des étapes n'a pas été réalisée, toutes les autres étapes doivent être défaites (“rolled back”), laissant l'état de la base inchangé.

L'atomicité est manifestement d'une extrême importance dans les systèmes financiers, où des balances non équilibrées du fait d'échecs partiels seraient une catastrophe. Les tableurs et les bases de données qui ne supportent pas les transactions ne peuvent pas être atomiques.

Firebird est entièrement “piloté par les transactions”: rien ne peut arriver en dehors du contexte d'une transaction.

La Cohérence est la capacité du moteur de bases de données à protéger la base de tous les changements d'état qui pourraient laisser un ensemble de données désynchronisé par rapport à un autre ensemble de données. Par exemple, le système doit être capable de reconnaître qu'une facture est liée à un client et aux éléments facturés. Il doit être capable d'éviter, par exemple, la suppression d'un client s'il existe encore des factures pour ce client, et la suppression d'une facture qui a des éléments associés.

L'implémentation pratique de telles dépendances est faite par la déclaration de contraintes d'intégrité référentielles (“foreign keys”) renforcée par des déclencheurs automatiquement générés. (Les déclencheurs sont automatiquement générés ou définis dans des blocs de code qui s'exécutent quand un enregistrement est inséré, modifié ou supprimé.) Le système de bases de données qui dépend du code d'une application pour gérer des règles de cohérence ne sont pas conformes à la règle de cohérence ACID. Firebird respecte parfaitement les règles d'intégrité définies par la norme.

Firebird garanti aussi la cohérence quand une seule transaction est exécutée pour effectuer des changements sur plusieurs bases à la fois, c'est ce que l'on appelle le “two-phase commit”. Les systèmes qui peuvent accéder à plusieurs bases à la fois de manière concurrente sans la possibilité de synchroniser les changement dans toutes les bases ne respectent pas le principe de cohérence.

L'isolement décrit la possibilité du moteur de bases de données de permettre à chaque utilisateur (ou transaction) d'opérer comme s'il était le seul utilisateur (ou la seule transaction). Le mécanisme d'isolement doit être capable de garder la base cohérente pour chaque transaction tant qu'elle est en cours, indépendamment de tout changement intervenant dans d'autres transactions. Les systèmes de gestion de bases de données qui sont conformes à ce principe offre en général différents niveaux d'isolement, qui sont définis dans les normes ISO/ANSI SQL.

En plus du niveau d'isolement décrit ci-dessus (Concurrency ou Repeatable Read), qui doit être supporté, Firebird supporte aussi Read Committed (quand une transaction peut voir le travail validé par les autres transactions) et, à contrario, Consistency ou Table Stability (quand une transaction qui peut écrire dans la base bloque l'accès aux tables qu'elle utilise aux autres transactions capables d'écrire ).

La durabilité garanti que la base va garder trace des changements en cours de manière que l'état de la base ne soit pas affecté si une transaction est interrompue. De sorte que, même si le serveur de base de données est débranché en plein milieu d'une transaction, les serveurs de base de données conformes à la norme ACID doivent remettre la base dans un état cohérent à leur redémarrage.