Mayoritas perangkat lunak saat ini dikembangkan dengan paradigma pemrograman berorientasi objek. Namun, saat data disimpan dalam tabel relasional SQL, muncul kebutuhan akan lapisan terjemahan yang tidak natural antara objek kode dan baris tabel. Situasi ini dikenal sebagai ketidakcocokan impedansi objek-relasional. Bayangkan profil LinkedIn: setiap pengguna memiliki identitas unik, nama depan dan belakang yang tunggal, tetapi riwayat pekerjaan serta pendidikan bisa terdiri dari banyak entri. Pendekatan klasik menempatkan job dan education dalam tabel terpisah yang dihubungkan melalui kunci asing.
Pendekatan modern memungkinkan struktur tersebut dibenamkan dalam dokumen JSON atau XML pada satu baris, sehingga lokalisitas data lebih tinggi dan sebuah kueri sudah cukup. Sebaliknya, skema multi-tabel memaksa pengembang menjalankan banyak JOIN yang meruwetkan logika. Kelemahan muncul bila dokumen tersebut sekadar dikodekan sebagai teks biasa di kolom database. Mesin basis data kehilangan kemampuan menyelidiki nilai di dalamnya. Untuk representasi seperti resume, format JSON jauh lebih pas.
Latar belakang ketidakcocokan ini sebenarnya bukan barang baru. Pada era 1970-an, IBM merilis IMS yang menggunakan model hierarkis dengan kemiripan mencolok terhadap model dokumen JSON sekarang. Sistem itu handal untuk relasi satu-ke-banyak, tetapi menjadi sulit dirawat ketika harus menangani relasi banyak-ke-banyak. IMS tidak mendukung JOIN, sehingga programmer harus memutuskan antara menduplikasi data atau menyelesaikan referensi secara manual.
Keterbatasan IMS memicu lahirnya model relasional dan model jaringan. Model relasional yang digagas Edgar Codd akhirnya menang telak, sementara model jaringan perlahan tenggelam. Ironisnya, problem serupa dijumpai kembali oleh pengembang modern yang mengadopsi basis data dokumen. Sejarah tampak berulang, hanya beda kemasan.
Bila dibandingkan, basis data dokumen menawarkan kinerja lebih baik berkat lokalisitas penyimpanan serta keluwesan skema. Di sisi lain, basis data relasional menyediakan dukungan JOIN secara native dan lebih siap menangani relasi banyak-ke-satu maupun banyak-ke-banyak. Masing-masing membawa keuntungan yang tidak bisa diabaikan.
Istilah 'schema-less' yang sering disematkan pada basis data dokumen sejatinya menyesatkan. Skema implisit tetap ada, hanya saja interpretasinya terjadi saat pembacaan data, bukan saat penulisan. Fenomena ini disebut schema-on-read. Dokumen biasanya disimpan sebagai string panjang yang dikodekan JSON, XML, atau format biner seperti BSON. Bila aplikasi kerap membutuhkan dokumen utuh, penyimpanan berdampingan memberi keuntungan kecepatan. Namun, saat pembaruan, seluruh dokumen kerap harus ditulis ulang.
Di Indonesia, perdebatan ini memiliki dampak nyata. Perusahaan rintisan seperti Gojek dan Tokopedia serta berbagai sistem pemerintah dahulu mengandalkan PostgreSQL atau MySQL untuk menjamin integritas transaksional. Namun, banyak aplikasi baru memilih MongoDB demi keluwesan saat iterasi produk. Tim teknis lokal kerap terjebak pada mismatch ketika skala pengguna melonjak dan kebutuhan kueri melintasi batas dokumen.
Bandingkan dengan praktik umum di Tanah Air yang menggunakan ORM seperti Hibernate atau Sequelize untuk menjembatani objek dan tabel. Pendekatan tersebut mengurangi beban kode, tetapi tidak menyembuhkan akar masalah. Selain itu, JOIN di sisi klien pada basis data dokumen umumnya lebih lambat karena memerlukan tambahan putaran jaringan dan tidak memanfaatkan pengoptimal kueri database. Hal ini krusial bagi aplikasi berlatensi rendah di wilayah dengan konektivitas tidak merata.
Sebuah paparan teknis di kalangan pengembang mencatat bahwa penyimpanan wilayah geografis sebagai identitas standar, bukan teks bebas, memberi keuntungan gaya penulisan seragam serta pengurangan ambiguitas. Kemudahan pembaruan dan dukungan lokalisasi ikut didapat. Praktik serupa terlihat pada basis data alamat di Indonesia yang menggunakan kode kelurahan dan kecamatan terstandar agar pencarian tetap konsisten.
Sumber yang sama menegaskan bahwa JOIN sisi klien secara umum lebih lambat daripada JOIN basis data karena butuh perjalanan jaringan ekstra dan luput dari optimizer. Untuk produk digital Indonesia yang melayani jutaan pengguna di luar Jawa, latensi tambahan dapat merusak pengalaman. Oleh karena itu, pemilihan model data harus didasarkan beban kerja nyata, bukan tren.
Konvergensi kedua dunia kini berjalan. Kebanyakan basis data relasional, kecuali MySQL, telah mendukung XML sejak pertengahan 2000-an dan kemudian JSON. RethinkDB sebagai basis data dokumen menyediakan JOIN bergaya relasional. Beberapa driver MongoDB secara otomatis menyelesaikan referensi, meniru JOIN di klien. Sementara itu, Spanner milik Google menawarkan lokalisitas serupa dengan model relasional.
Ke depan, arsitek perangkat lunak disarankan membatasi ukuran dokumen dan menghindari pembaruan yang mengembang. Tim engineering Indonesia perlu menimbang trade-off secara matang, tidak sekadar mengikuti euforia NoSQL. Pendekatan hibrida yang mengawinkan relasional dan dokumen diprediksi mendominasi arsitektur enterprise dalam lima tahun mendatang.