Paradigma alami dalam teori untuk menyimpan XBRL dalam database adalah OLAP, karena XBRL adalah tentang kubus data. OLAP di atas database relasional akan disebut ROLAP.
Ini bukan masalah sepele, karena fakta yang diambil dari sejumlah besar taksonomi dapat membentuk kubus yang sangat besar dan jarang (untuk pengarsipan SEC dimensinya 10k+), dan juga karena membuat skema SQL memerlukan pengetahuan taksonomi sebelum impor apa pun. Jika taksonomi baru muncul, seseorang perlu ETL ulang semuanya. Ini tidak membuat database relasional cocok sebagai solusi umum.
Jika pengajuan memiliki taksonomi yang sama dan taksonominya sangat sederhana (seperti dalam:tidak terlalu banyak dimensi), dimungkinkan untuk membuat pemetaan ad-hoc untuk menyimpan semua fakta dalam satu tabel dengan banyak baris di ROLAP akal (fakta ke baris, aspek ke kolom). Beberapa vendor mengkhususkan diri dalam menyimpan fakta XBRL non-dimensi, dalam hal ini penawaran SQL tradisional (atau "pasca-SQL" yang diskalakan dengan baris) berfungsi dengan baik.
Beberapa vendor membuat tabel untuk setiap hypercube XBRL dalam taksonomi, dengan skema yang diturunkan dari jaringan definisi tetapi berbeda untuk setiap hypercube. Hal ini dapat menyebabkan banyak tabel dalam database, dan memerlukan banyak gabungan untuk kueri yang melibatkan banyak hypercubes.
Beberapa vendor lain membuat asumsi tentang struktur XBRL yang mendasarinya, atau tentang jenis kueri yang perlu dijalankan oleh pengguna mereka. Membatasi ruang lingkup masalah memungkinkan menemukan arsitektur tertentu atau skema SQL yang juga dapat melakukan pekerjaan untuk kebutuhan khusus ini.
Terakhir, untuk mengimpor sejumlah besar pengajuan, dimungkinkan untuk membuat pemetaan generik di atas penyimpanan data NoSQL daripada database relasional. Fakta dalam jumlah besar dengan jumlah dimensi yang bervariasi cocok dengan kumpulan besar dokumen semi-terstruktur, dan jaringan cocok dengan baik dalam format hierarkis.
