TigerDB ne stocke pas lui-même les données mais encapsule un ou plusieurs moteurs de stockage, ce qui permet de ne pas perturber le système d’information en place (legacy) ou  d’utiliser les moteurs les mieux adaptés à une situation métier donnée.

TigerDB sait accéder, en lecture et en écriture, aux principaux type de moteurs : relationnels, documents, graphe etc. et prend en charge la synchronisation des données entre eux.

TigerDB propose, outre une API RESTFul complète, un langage d’accès aux données simple et puissant (le Dubnium Query Language ou DQL) permettant de récupérer en un seul objet métier au format JSON des données éparses, stockées sur différents moteurs, éventuellement en des lieux différents. DQL permet notamment des jointures entre différents stockages, par exemple entre une collection mongoDB et une table postgreSQL.

TigerDB assure automatiquement l’indexation de tout ou partie des données et permet au delà de la recherche « plain text » de répondre à certaines requêtes « classiques » de façon beaucoup plus performante, tout particulièrement dans un contexte « Big Data ».

Enfin, TigerDB autorise l’ingestion massive de données, même si elles ne respectent pas le schéma attendu, et effectue en tâche de fond la détection des anomalies pour permettre leur correction par un Data Steward.

En collaboration avec le microservice Soufre, TigerDB permet de stocker, mais aussi de gérer les métadonnées, en CRUD via une API RESTFul.

Ainsi, pour chaque structure de stockage (collection, table…), il est possible de gérer les types de données, les contraintes, les références, les opérations… ce qui permet à TigerDB d’effectuer tous les contrôles nécessaires lors des phases de création ou modification d’objets métier (cycle de vie).