Performa database menjadi salah satu faktor penting dalam pengembangan aplikasi web modern. Query yang terlalu berat atau overhead pada lapisan ORM dapat meningkatkan latency, terutama ketika aplikasi harus memproses banyak data dalam waktu singkat. Drizzle ORM terus dikembangkan untuk memberikan pengalaman bekerja dengan database yang ringan, type-safe, dan memiliki overhead runtime yang rendah. Dalam perkembangan menuju Drizzle ORM 1.0, sejumlah perubahan internal mulai berfokus pada pemrosesan hasil query dan efisiensi komunikasi dengan database.
Salah satu pembaruan yang menarik adalah hadirnya JIT Mappers, sistem pemetaan hasil query yang dapat mengurangi pekerjaan berulang ketika data database diubah menjadi objek JavaScript. Selain itu, Drizzle memperkenalkan sistem codecs dan melakukan pengembangan pada Relational Query Builder V2. Berdasarkan benchmark yang dipublikasikan tim Drizzle, perubahan pada v1.0.0-rc.1 menunjukkan penurunan latency sekitar 25–30% dalam pengujian mereka.
Perkembangan Drizzle ORM Menuju Versi 1.0
Drizzle ORM mengalami sejumlah perubahan besar dalam perjalanan menuju versi 1.0. Pada September 2026, daftar rilis resmi mencantumkan versi stabil 0.45.3 sekaligus beberapa versi pra-rilis 1.0.0, termasuk v1.0.0-rc.4. Rangkaian rilis tersebut menunjukkan bahwa pengembangan Drizzle tidak hanya berfokus pada penambahan fitur, tetapi juga perombakan internal untuk meningkatkan performa dan konsistensi API.
Pada perkembangan v1, beberapa API lama juga mulai ditinggalkan. Salah satunya adalah Relational Queries v1 (RQBv1) yang digantikan oleh Relational Queries v2 dengan API defineRelations(). Perubahan ini menjadi bagian dari upaya menyederhanakan dan memperbarui arsitektur relational query di Drizzle.
JIT Mappers untuk Mengurangi Overhead Query
Salah satu fitur yang paling berkaitan dengan performa adalah JIT Mappers. JIT atau Just-In-Time Mappers bekerja dengan membuat fungsi JavaScript khusus untuk memetakan hasil database menjadi objek JavaScript.
Pada mapper biasa, Drizzle perlu melakukan berbagai pemeriksaan ketika memproses setiap baris hasil query. Proses tersebut dapat mencakup pengecekan metadata kolom, decoder, nilai null, codec, hingga struktur objek bertingkat.
JIT Mappers mengubah pendekatan tersebut dengan menghasilkan fungsi yang sudah disesuaikan berdasarkan struktur query. Fungsi tersebut kemudian dapat digunakan kembali untuk baris-baris berikutnya sehingga sebagian pekerjaan interpretasi tidak perlu dilakukan berulang kali.
Fitur ini dapat diaktifkan melalui konfigurasi jit:
import { drizzle } from "drizzle-orm/...";
const db = drizzle({
client,
jit: true
});
JIT Mappers bersifat opt-in, sehingga developer tetap dapat menggunakan mapper biasa. Dokumentasi Drizzle juga menjelaskan bahwa sistem akan melakukan pengecekan kompatibilitas runtime dan dapat kembali menggunakan mapper reguler jika pembuatan fungsi dinamis tidak tersedia.
Bagaimana JIT Mappers Mempercepat Pemrosesan Data?
Bayangkan sebuah aplikasi melakukan query yang menghasilkan ribuan baris. Setiap baris perlu dikonversi dari format hasil database menjadi objek JavaScript yang dapat digunakan aplikasi.
Dengan pendekatan mapper tradisional, proses tersebut dapat melibatkan pemeriksaan metadata untuk setiap baris. Semakin banyak data yang dikembalikan, semakin banyak pekerjaan yang harus dilakukan di sisi ORM.
JIT Mappers mencoba mengurangi overhead tersebut dengan membuat fungsi pemetaan yang lebih spesifik berdasarkan struktur hasil query. Metadata yang sebelumnya harus diperiksa secara berulang dapat “ditanamkan” ke dalam fungsi yang sudah dikompilasi.
Hasilnya, proses mapping dapat menjadi lebih dekat dengan pekerjaan yang dilakukan oleh database driver secara langsung. Drizzle sendiri menjelaskan JIT Mappers sebagai pendekatan untuk membuat row mapping secepat mungkin dengan mengurangi overhead interpretasi.
Sistem Codecs Baru di Drizzle ORM
Selain JIT Mappers, Drizzle juga memperkenalkan sistem codecs. Sistem ini menangani proses transformasi dan normalisasi data antara database driver dan aplikasi.
Perbedaan cara driver mengembalikan tipe data tertentu dapat menyebabkan kebutuhan pemrosesan tambahan. Codecs dirancang untuk membuat proses tersebut lebih konsisten, termasuk ketika data muncul melalui query biasa, objek JSON, maupun PostgreSQL array.
Menurut catatan rilis Drizzle v1.0.0-rc.1, perubahan internal tersebut juga mengurangi pekerjaan yang dianggap tidak diperlukan. Dalam benchmark yang dilakukan tim Drizzle, mereka melaporkan penurunan latency sekitar 25–30% serta peningkatan throughput dari sekitar 14.500 menjadi 15.300 request per detik pada pengujian tertentu.
Angka tersebut perlu dibaca sebagai hasil benchmark Drizzle, bukan sebagai angka performa yang otomatis berlaku untuk setiap aplikasi. Performa nyata tetap dipengaruhi oleh jenis database, struktur tabel, indeks, ukuran data, driver, jaringan, dan pola query.
Relational Query Builder V2
Perubahan lain yang penting adalah perkembangan Relational Query Builder V2 atau RQBv2. Sistem ini ditujukan untuk mempermudah pengambilan data yang memiliki hubungan antar tabel tanpa harus membuat banyak query secara manual.
Dalam perkembangan menuju v1, RQBv1 mulai dihapus dan developer diarahkan menggunakan sistem relational query baru dengan defineRelations().
Contoh pendekatan relasi baru dapat menggunakan struktur seperti:
import { defineRelations } from "drizzle-orm";
const relations = defineRelations(schema, (r) => ({
users: {
posts: r.many.posts(),
profile: r.one.profiles(),
},
posts: {
author: r.one.users({
from: posts.authorId,
to: users.id,
}),
},
}));
Dengan model seperti ini, hubungan antar tabel dapat didefinisikan secara eksplisit dan digunakan kembali dalam query aplikasi.
Mengurangi Risiko Query Berlebihan
Salah satu masalah yang sering muncul ketika mengambil data relasional adalah N+1 query problem. Masalah ini terjadi ketika aplikasi menjalankan satu query untuk data utama kemudian menjalankan query tambahan berulang kali untuk setiap data terkait.
Pendekatan relational query Drizzle dirancang agar pengambilan data relasional dapat dilakukan dengan lebih efisien. Tim Drizzle juga menyebut prepared statements dan relational queries sebagai bagian dari pendekatan mereka untuk menjaga runtime overhead tetap rendah sekaligus menghindari masalah N+1 pada relational queries.
Namun, penggunaan ORM tetap perlu disertai pemahaman mengenai SQL. Query yang terlihat sederhana di kode aplikasi tetap dapat menghasilkan operasi database yang berat apabila struktur relasi, filter, atau indeks tidak dirancang dengan baik.
Perubahan pada MySQL dan SQLite
Pengembangan menuju Drizzle 1.0 tidak hanya berfokus pada PostgreSQL. Pada v1.0.0-rc.3, Drizzle melakukan sejumlah perubahan internal untuk MySQL, termasuk refactoring session dan unified query preparation. RQBv2 juga beralih ke pendekatan array mode dan mapper non-JIT yang dioptimalkan untuk query reguler.
Kemudian pada v1.0.0-rc.4, sejumlah perubahan diterapkan pada SQLite. RQBv1 dihapus dari SQLite, RQBv2 menggunakan array mode, dan optimized default query mappers diaktifkan. Struktur session SQLite juga diperbarui agar lebih mendekati implementasi PostgreSQL dan MySQL.
Perubahan lintas database tersebut penting karena developer dapat menggunakan pendekatan Drizzle yang relatif konsisten meskipun backend database yang digunakan berbeda.
Drizzle Kit Juga Mendapat Pembaruan
Selain drizzle-orm, ekosistem Drizzle memiliki Drizzle Kit yang digunakan untuk kebutuhan schema dan migration. Pada daftar rilis terbaru, [email protected] tercatat sebagai rilis terbaru yang dipublikasikan bersama [email protected].
Drizzle Kit membantu developer mengelola perubahan struktur database berdasarkan schema yang digunakan dalam project. Proses migration menjadi bagian penting karena perubahan tabel pada aplikasi produksi harus dapat dilacak dan diterapkan secara konsisten.
Dalam pengembangan menuju versi 1.0, sistem migration juga mendapatkan sejumlah perbaikan, termasuk peningkatan pemeriksaan terhadap konflik migration dan perubahan schema.
Dukungan Database dan Driver Semakin Luas
Perkembangan Drizzle 1.0 juga memperluas dukungan terhadap berbagai lingkungan database. Dokumentasi perubahan v0 ke v1 mencantumkan dukungan untuk MSSQL, CockroachDB, serta Netlify DB.
Pada rilis 0.45.3, misalnya, Drizzle menambahkan Netlify DB driver yang dikembangkan dan dipelihara oleh tim Netlify. Penggunaan driver tersebut memungkinkan aplikasi menggunakan Drizzle melalui integrasi database Netlify.
Perkembangan ini membuat Drizzle tidak hanya menarik untuk aplikasi PostgreSQL sederhana, tetapi juga untuk project yang membutuhkan kombinasi database dan runtime berbeda.
Apakah Drizzle ORM Benar-Benar Cepat?
Drizzle memang memiliki fokus kuat pada performa, tetapi istilah “cepat” tidak bisa hanya ditentukan dari ORM. Database tetap menjadi komponen utama dalam menentukan waktu eksekusi query.
Misalnya, query yang tidak menggunakan indeks dengan tepat tetap dapat lambat meskipun ORM yang digunakan memiliki overhead rendah. Begitu juga dengan query yang mengambil terlalu banyak kolom atau menghasilkan data dalam jumlah sangat besar.
Drizzle memosisikan dirinya sebagai lapisan yang relatif tipis di atas SQL. Pendekatan tersebut membantu developer tetap dekat dengan struktur query database sekaligus mendapatkan manfaat dari TypeScript dan type safety. Tim Drizzle juga menyediakan benchmark untuk membandingkan beberapa konfigurasi dan implementasi, tetapi mereka sendiri memberi catatan bahwa benchmark tersebut perlu dipertimbangkan sesuai konteks.
Karena itu, performa aplikasi sebaiknya tetap diuji menggunakan workload yang mendekati kondisi sebenarnya.
Hal yang Perlu Diperhatikan Saat Mengoptimalkan Query
Menggunakan versi Drizzle terbaru bukan satu-satunya cara meningkatkan performa aplikasi. Developer tetap perlu memperhatikan beberapa aspek database.
Pertama, gunakan index pada kolom yang sering digunakan untuk pencarian, filtering, sorting, atau join. Kedua, hindari mengambil seluruh kolom jika aplikasi hanya membutuhkan beberapa field.
Ketiga, gunakan pagination untuk dataset besar. Mengambil puluhan ribu baris sekaligus dapat membebani database maupun server aplikasi.
Keempat, gunakan prepared statements pada skenario yang sesuai dan hindari membuat query berulang yang sebenarnya dapat digabungkan.
Terakhir, ukur performa menggunakan data dan workload nyata. Dengan cara tersebut, developer dapat mengetahui apakah bottleneck berasal dari ORM, query SQL, database, jaringan, atau proses lain dalam aplikasi.
