Det naturlige paradigme i teorien for lagring af XBRL i en database ville være OLAP, fordi XBRL handler om datakuber. OLAP oven på en relationsdatabase kaldes ROLAP.
Dette er ikke et trivielt problem, fordi fakta taget fra et stort antal taksonomier kan danne en meget stor og sparsom kube (for SEC-arkiveringer er det 10k+ dimensioner), og også fordi oprettelse af et SQL-skema kræver at kende taksonomierne før enhver import. Hvis nye taksonomier kommer op, skal man gen-ETL alt. Dette gør ikke relationsdatabaser egnede som en generel løsning.
Hvis ansøgningerne deler den samme taksonomi, og taksonomien dog er meget enkel (som i:ikke for mange dimensioner), er det muligt at komme op med en ad-hoc mapping for at gemme alle fakta i en enkelt tabel med mange rækker i ROLAP'en forstand (fakta til rækker, aspekter til kolonner). Nogle leverandører er specialiserede i at gemme ikke-dimensionelle XBRL-fakta, i hvilket tilfælde traditionelle SQL-tilbud (eller "post-SQL", der skaleres med rækker)-tilbud fungerer godt.
Nogle leverandører opretter en tabel for hver XBRL-hyperkube i taksonomien med et skema afledt af definitionsnetværket, men forskelligt for hver hyperkube. Dette kan føre til mange tabeller i databasen og kræver mange joinforbindelser til forespørgsler, der involverer flere hyperkuber.
Nogle andre leverandører gør antagelser om den underliggende XBRL-struktur eller om den slags forespørgsler, som deres brugere skal køre. Begrænsning af omfanget af problemet gør det muligt at finde specifikke arkitekturer eller SQL-skemaer, der også kan udføre opgaven til disse specifikke behov.
Endelig, for at importere store mængder arkiveringer, er det muligt at bygge generiske kortlægninger oven på NoSQL-datalagre i stedet for relationelle databaser. Et stort antal fakta med et varierende antal dimensioner passer ind i store samlinger af semistrukturerede dokumenter, og netværk passer godt i et hierarkisk format.