Det naturliga paradigmet i teorin för att lagra XBRL i en databas skulle vara OLAP, eftersom XBRL handlar om datakuber. OLAP ovanpå en relationsdatabas skulle kallas ROLAP.
Detta är inte ett trivialt problem, eftersom fakta hämtade från ett stort antal taxonomier kan bilda en mycket stor och gles kub (för SEC-filer är det 10k+ dimensioner), och även för att skapa ett SQL-schema kräver att man känner till taxonomierna innan import. Om nya taxonomier dyker upp måste man om-ETL allt. Detta gör inte relationsdatabaser lämpliga som en generell lösning.
Om ansökningarna delar samma taxonomi och taxonomin är väldigt enkel (som i:inte för många dimensioner), är det möjligt att komma med en ad-hoc-mappning för att lagra alla fakta i en enda tabell med många rader i ROLAP mening (fakta till rader, aspekter till kolumner). Vissa leverantörer är specialiserade på att lagra icke-dimensionella XBRL-fakta, i vilket fall traditionella SQL-erbjudanden (eller "post-SQL" som skalas med rader) fungerar bra.
Vissa leverantörer skapar en tabell för varje XBRL-hyperkub i taxonomin, med ett schema härlett från definitionsnätverket men olika för varje hyperkub. Detta kan leda till många tabeller i databasen och kräver många kopplingar för frågor som involverar flera hyperkuber.
Vissa andra leverantörer gör antaganden om den underliggande XBRL-strukturen, eller om vilken typ av frågor som deras användare behöver köra. Genom att begränsa problemets omfattning kan du hitta specifika arkitekturer eller SQL-scheman som också kan göra jobbet för dessa specifika behov.
Slutligen, för att importera stora mängder arkiv, är det möjligt att bygga generiska mappningar ovanpå NoSQL-datalager snarare än relationsdatabaser. Ett stort antal fakta med varierande antal dimensioner passar i stora samlingar av semistrukturerade dokument, och nätverk passar bra i ett hierarkiskt format.