Teoretickým přirozeným paradigmatem pro ukládání XBRL v databázi by bylo OLAP, protože XBRL je o datových kostkách. OLAP nad relační databází by se nazýval ROLAP.
Nejde o triviální problém, protože fakta převzatá z velkého množství taxonomií mohou tvořit velmi velkou a řídkou krychli (pro podání SEC je to 10k+ rozměrů), a také proto, že vytvoření schématu SQL vyžaduje před jakýmkoli importem znát taxonomie. Pokud se objeví nové taxonomie, je třeba vše znovu ETL. To nedělá relační databáze vhodné jako obecné řešení.
Pokud podání sdílí stejnou taxonomii a taxonomie je velmi jednoduchá (jako v:ne příliš mnoho dimenzí), je možné přijít s ad-hoc mapováním pro uložení všech faktů do jediné tabulky s mnoha řádky v ROLAP. smysl (fakta k řádkům, aspekty ke sloupcům). Někteří prodejci se specializují na ukládání bezrozměrných XBRL faktů, v takovém případě fungují dobře tradiční nabídky SQL (nebo „post-SQL“, které se škálují podle řádků).
Někteří prodejci vytvářejí tabulku pro každou hyperkrychli XBRL v taxonomii se schématem odvozeným z definiční sítě, ale pro každou hyperkrychli jiným. To může vést k mnoha tabulkám v databázi a vyžaduje to mnoho spojení pro dotazy zahrnující více hyperkrychlí.
Někteří jiní dodavatelé vytvářejí předpoklady o základní struktuře XBRL nebo o druhu dotazů, které jejich uživatelé potřebují spouštět. Omezení rozsahu problému umožňuje najít konkrétní architektury nebo schémata SQL, která mohou také provést práci pro tyto specifické potřeby.
A konečně, pro import velkého množství souborů je možné vytvořit obecná mapování na úložištích dat NoSQL spíše než na relačních databázích. Velké množství faktů s různým počtem dimenzí se vejde do velkých sbírek polostrukturovaných dokumentů a sítě se dobře hodí do hierarchického formátu.