Migrasi Skema Database Tanpa Downtime: Pola Expand dan Contract

TL;DR: Expand and contract adalah pola migrasi skema database yang memecah satu perubahan berisiko menjadi beberapa langkah aman. Tahapnya: tambah struktur baru tanpa menghapus yang lama, tulis ke keduanya, pindahkan pembacaan, baru hapus yang lama. Dengan pola ini, aplikasi versi lama dan versi baru bisa berjalan berdampingan sehingga migrasi tidak butuh jendela downtime.

Perubahan skema database di produksi punya reputasi buruk karena umumnya dikerjakan sebagai satu langkah besar. Kolom nama_lengkap dipecah jadi nama_depan dan nama_belakang, deploy dijalankan, dan selama beberapa detik antara migrasi dan rilis aplikasi, ada versi kode yang membaca kolom yang sudah tidak ada.

Pada website bisnis dengan lalu lintas rendah, jendela itu tidak terasa. Pada aplikasi yang menerima order sepanjang hari, beberapa detik itu berarti transaksi gagal. Yang perlu diubah bukan jam kerjanya, tapi urutannya.

Kenapa Migrasi Satu Langkah Berisiko

Deployment modern hampir selalu bertahap. Server lama dan server baru berjalan bersamaan selama beberapa menit. Artinya ada periode ketika dua versi kode mengakses satu database yang sama.

Migrasi satu langkah mengasumsikan hal yang tidak benar: bahwa kode dan skema berganti pada detik yang sama. Begitu asumsi itu gugur, muncul kesalahan yang sulit dilacak karena hanya terjadi selama jendela transisi. Ini juga alasan kenapa strategi rollback sering gagal: kode bisa dikembalikan, tapi kolom yang sudah terhapus tidak.

Untuk konteks arsitektur yang lebih luas, pilihan tech stack dan pengaturan connection pooling ikut menentukan seberapa besar dampak sebuah migrasi terasa di sisi pengguna.

Empat Tahap Expand and Contract

Kunci keamanannya ada di tahap satu: kolom baru harus boleh kosong dan tidak boleh punya constraint ketat di awal. Menambahkan kolom NOT NULL dengan nilai default pada tabel besar bisa memicu penguncian tabel yang lama di beberapa versi PostgreSQL dan MySQL. Dokumentasi PostgreSQL soal ALTER TABLE merinci operasi mana yang memerlukan rewrite penuh dan mana yang tidak. Bacalah sebelum menjalankan migrasi pada tabel jutaan baris.

Tahap keempat sebaiknya ditunda, bukan dikejar. Membiarkan kolom lama menganggur selama satu atau dua siklus rilis jauh lebih murah daripada memulihkan data yang terlanjur dihapus.

Backfill yang Tidak Membebani Database

Mengisi data lama ke kolom baru dengan satu perintah UPDATE pada tabel besar adalah cara cepat membuat database melambat. Alternatifnya, jalankan dalam batch: proses beberapa ribu baris, jeda sejenak, lanjutkan.

Pola yang saya pakai pada proyek berbasis Supabase: skrip backfill berjalan sebagai tugas terjadwal di luar jam sibuk, memproses batch berdasarkan rentang id, dan mencatat posisi terakhir supaya bisa dilanjutkan kalau terhenti. Cara ini membuat proses bisa dihentikan kapan saja tanpa meninggalkan keadaan setengah jadi.

Pengendalian pembacaan lebih mudah lagi kalau aplikasi sudah memakai feature flag. Pemindahan sumber baca dari kolom lama ke kolom baru cukup jadi perubahan konfigurasi, bukan deployment baru, sehingga bisa dibalik dalam hitungan detik.

Checklist Sebelum Menjalankan di Produksi

• Migrasi sudah diuji pada salinan data dengan volume mendekati produksi, bukan hanya data contoh
• Setiap langkah punya jalur balik yang jelas, kecuali tahap contract
• Operasi yang memicu penguncian tabel sudah diidentifikasi lebih dulu
• Backfill berjalan dalam batch dengan penanda posisi
• Ada pemantauan kesalahan aktif selama dan sesudah rilis
• Jeda minimal satu siklus rilis sebelum menghapus struktur lama

Saat menangani perpindahan struktur konten pada proyek web berbasis Next.js dan Supabase, langkah yang paling sering diremehkan adalah poin pertama. Migrasi yang berjalan dalam hitungan milidetik di database lokal bisa memakan waktu jauh lebih lama pada tabel produksi, dan perbedaan itu baru terlihat kalau volumenya diuji.

Pertanyaan Umum

Apakah pola ini berlaku untuk semua jenis database?

Prinsipnya berlaku umum untuk database relasional seperti PostgreSQL dan MySQL. Detail operasi mana yang mengunci tabel berbeda antar mesin dan antar versi, jadi periksa dokumentasi versi yang Anda pakai.

Berapa lama sebaiknya struktur lama dipertahankan?

Umumnya satu sampai dua siklus rilis setelah pembacaan dipindahkan sepenuhnya. Rentang ini memberi waktu memastikan tidak ada kode atau laporan yang masih menyentuh kolom lama.

Apakah pola ini membuat kode jadi lebih rumit?

Sementara iya, karena ada periode dual write. Kerumitan itu bersifat sementara dan hilang setelah tahap contract, sementara risiko downtime yang dihindari bersifat permanen.

Kapan migrasi satu langkah masih masuk akal?

Ketika aplikasi memang boleh berhenti sejenak, misalnya alat internal dengan pengguna terbatas, atau saat perubahan hanya menambah tabel baru yang belum dipakai kode mana pun.

Urutan Lebih Menentukan daripada Waktu

Migrasi tengah malam mengurangi jumlah pengguna yang terdampak, tapi tidak mengurangi risikonya. Expand and contract menyerang sumber masalahnya: asumsi bahwa kode dan skema berubah bersamaan. Begitu asumsi itu dilepas, migrasi berhenti jadi peristiwa dan berubah jadi rutinitas.