O paradigma natural em teoria para armazenar XBRL em um banco de dados seria OLAP, porque XBRL é sobre cubos de dados. O OLAP sobre um banco de dados relacional seria chamado de ROLAP.

Este não é um problema trivial, porque fatos retirados de um grande número de taxonomias podem formar um cubo muito grande e esparso (para arquivamentos SEC são 10k+ dimensões), e também porque criar um esquema SQL requer conhecer as taxonomias antes de qualquer importação. Se novas taxonomias surgirem, é preciso re-ETL tudo. Isso não torna os bancos de dados relacionais adequados como uma solução geral.

Se os arquivos compartilham a mesma taxonomia e a taxonomia é muito simples (como em:não são muitas dimensões), é possível criar um mapeamento ad-hoc para armazenar todos os fatos em uma única tabela com muitas linhas no ROLAP sentido (fatos para linhas, aspectos para colunas). Alguns fornecedores são especializados em armazenar fatos XBRL não dimensionais, caso em que as ofertas de SQL tradicional (ou "pós-SQL" que escala com linhas) funcionam bem.

Alguns fornecedores criam uma tabela para cada hipercubo XBRL na taxonomia, com um esquema derivado da rede de definição, mas diferente para cada hipercubo. Isso pode levar a muitas tabelas no banco de dados e requer muitas junções para consultas envolvendo vários hipercubos.

Alguns outros fornecedores fazem suposições sobre a estrutura XBRL subjacente ou sobre o tipo de consultas que seus usuários precisam executar. Restringir o escopo do problema permite encontrar arquiteturas específicas ou esquemas SQL que também podem fazer o trabalho para essas necessidades específicas.

Finalmente, para importar grandes quantidades de arquivos, é possível construir mapeamentos genéricos sobre armazenamentos de dados NoSQL em vez de bancos de dados relacionais. Grandes números de fatos com um número variável de dimensões se encaixam em grandes coleções de documentos semiestruturados, e as redes se encaixam bem em um formato hierárquico.