Естествената парадигма на теория за съхраняване на XBRL в база данни би била OLAP, тъй като XBRL е за кубчета данни. OLAP върху релационна база данни ще се нарича ROLAP.
Това не е тривиален проблем, защото фактите, взети от голям брой таксономии, могат да образуват много голям и рядък куб (за SEC документите са 10k+ измерения), а също и защото създаването на SQL схема изисква познаване на таксономиите преди всяко импортиране. Ако се появят нови таксономии, човек трябва да пре-ETL всичко. Това не прави релационните бази данни подходящи като общо решение.
Ако документите споделят една и съща таксономия и таксономията е много проста (като например:не твърде много измерения), възможно е да се измисли ad-hoc съпоставяне за съхраняване на всички факти в една таблица с много редове в ROLAP смисъл (факти към редове, аспекти към колони). Някои доставчици са специализирани в съхраняването на безразмерни XBRL факти, като в този случай традиционните SQL (или "пост-SQL", които мащабират с редове) предложения работят добре.
Някои доставчици създават таблица за всеки XBRL хиперкуб в таксономията, със схема, извлечена от мрежата за дефиниции, но различна за всеки хиперкуб. Това може да доведе до много таблици в базата данни и изисква много обединения за заявки, включващи множество хиперкубове.
Някои други доставчици правят предположения за основната XBRL структура или за вида заявки, които техните потребители трябва да изпълняват. Ограничаването на обхвата на проблема позволява намирането на специфични архитектури или SQL схеми, които също могат да свършат работата за тези специфични нужди.
И накрая, за импортиране на големи количества файлове е възможно да се изградят общи съпоставяния върху хранилища на NoSQL данни, а не релационни бази данни. Голям брой факти с различен брой измерения се вписват в големи колекции от полуструктурирани документи, а мрежите се вписват добре в йерархичен формат.
