Hijrah Backend (9): Epilog, MySQL, PostgreSQL, Lalu MySQL Lagi

Seri ini sudah ditutup di episode lalu. Tapi setiap perjalanan panjang selalu punya satu cerita yang tidak muat di badan utama, dan cerita ini memang terjadi setelah hampir semua episode lain ditulis. Anggap saja adegan pasca-kredit di film: layar sudah gelap, lampu sudah nyala, tapi ada satu adegan lagi hehe.

Ini kisah tentang mesin database yang diminta pindah haluan dua kali. Dan soal siapa yang pegang kemudi saat itu: bukan saya, dan Anda mungkin sudah bisa menebak hahaha.

Visi Awal: Satu PostgreSQL untuk Semua #

Arah awalnya jelas dan tertulis. Di grup atasan, awal 2025, kalimatnya keluar dengan mantap:¹ cloud plus Go plus PostgreSQL adalah keharusan. Satu mesin untuk semuanya, satu dialek SQL, satu antrian yang perlu dipelajari. Secara visi, itu indah, dan saya jujur saja ikut antusias.

Kerjaannya juga nyata: konversi skema dari MySQL, perbaikan tipe data yang tidak punya padanan langsung, import data yang konflik di sana-sini, sampai membangun ulang modelnya di Go. Sampai satu fitur yang membuat saya bangga: pembaruan real-time antar aplikasi dibangun di atas LISTEN/NOTIFY bawaan PostgreSQL.² Tidak butuh message broker tambahan untuk kasus itu; database-nya sendiri yang mengetuk pintu. Rakus sedikit, tapi rakusnya teknis hehe~

Pulang, Nak #

Lalu, sekitar setahun kemudian, arah angin berubah. Keputusan datang: sistem warisan tetap MySQL, dan data domain utama kembali ke MySQL. PostgreSQL tidak dihapus; dia dipindahkan ke pangkalan yang lebih cocok: data time-series lokasi, yang memang paling rakus dan paling butuh partisi waktu.

Dari kacamata bisnis, keputusan itu punya logikanya: data yang sama tidak perlu dirawat di dua mesin dengan dua aturan, dan sistem warisan yang masih hidup memang bertahan lebih lama dari rencana siapa pun. Saya tidak berdebat dengan logikanya.

Tapi biayanya mendarat ke tempat yang sama seperti biasa: ke meja saya.

Aplikasi yang sudah lahir dan tumbuh di dialek PostgreSQL tiba-tiba harus hidup di dialek MySQL: sintaks yang beda, perilaku standard library SQL yang beda, tipe yang beda nama dan beda mood. Error bermunculan di tempat yang kemarin masih hijau. Optimasi LISTEN/NOTIFY yang sudah jadi? Menganggur. Dan saya? Saya mengerjakan hal yang sama untuk kedua kalinya, dengan tangan yang sudah hafal jalan yang salah hehe~

Yang Tersisa dari Dua Dunia #

Hasil akhirnya terlihat seperti damai setelah duel: MySQL memegang data domain, PostgreSQL memegang data lokasi. Dua mesin, dua peran, tidak saling mengganggu. Bukan arsitektur yang lahir dari gambar rapi di whiteboard; dia lahir dari dua keputusan besar yang berbalik arah, dan deployment yang harus tetap hidup di antara keduanya.

Kalau Anda bertanya mana yang benar: keduanya benar, di waktunya masing-masing. Visi awal benar sebagai visi; keputusan balik benar sebagai keseimbangan biaya. Yang tidak benar adalah mengira arah arsitektur tidak akan pernah berubah, lalu membangun segalanya tanpa rencana cadangan. Itu kesalahan saya, dan dia saya bayar tunai hahaha.

Dan Frontend? Sama Saja #

Supaya adil, warisan yang tidak konsisten itu ternyata tidak berhenti di backend. Saat mulai menyentuh frontend v3 (yang port tipis dari v2), luka-lama yang sama tercium lagi dari sisi seberang: field yang sumbernya berpindah-pindah, konvensi penamaan yang berganti-ganti era, dan kode yang membuat saya, seorang backend engineer biasa, bisa mencium bau spaghetti tanpa perlu jago frontend hehe~

Tapi itu cerita untuk seri lain, mungkin. Yang ini sudah cukup panjang.

Pelajaran Epilog #

1. Hitung biaya balik sebelum berangkat. Migrasi mesin database itu bukan satu jalan; itu jalan pulang-pergi kalau keputusannya tidak dipagari dengan data.
2. Fleksibilitas dialek SQL itu mahal. Kalau mau bisa pindah-pindah mesin, jangan menyentuh fitur khasnya (iya, termasuk LISTEN/NOTIFY-ku yang malang). Kalau mau memakai fitur khasnya, jangan berjanji bisa pindah. Pilih satu.
3. Satu data, satu rumah. Dua mesin boleh, asal perannya tidak tumpang tindih. Yang melelahkan bukan jumlahnya, tapi tumpang tindihnya.
4. Keputusan di atas gaji Anda tetap keputusan yang harus dijalani. Tugas kita bukan menang di rapat; tugas kita memastikan sistem tetap hidup setelah rapat selesai, sambil menyimpan catatan biayanya hehe.

Dengan ini, benar-benar tutup. Terima kasih sudah membaca sampai adegan pasca-kredit. Semoga armada kalian (kalau punya) selalu bicara, dan mesin databasenya tidak pindah haluan.

Sekian. Salam.