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



Seri ini sudah ditutup di episode lalu. Namun ada satu cerita yang tidak sempat masuk ke bagian utama. Kejadiannya berlangsung setelah hampir semua episode lain ditulis. Anggap saja adegan pasca-kredit: layar sudah gelap, lampu sudah menyala, tapi masih ada satu adegan lagi hehe.

Ini kisah tentang mesin database yang dua kali diminta pindah haluan. Soal siapa yang memegang kemudi, bukan saya. Mungkin Anda sudah bisa menebak hahaha.

Rencana Awalnya: PostgreSQL untuk Semua #

Arah awalnya jelas dan tertulis. Pada awal 2025, di grup atasan, pesannya disampaikan dengan mantap:1 cloud plus Go plus PostgreSQL adalah keharusan. Satu mesin untuk semuanya, satu dialek SQL, satu antrean teknologi yang perlu dipelajari. Visinya terdengar bagus, dan saya ikut antusias.

Pekerjaannya lumayan banyak: konversi skema dari MySQL, bereskan tipe data yang tidak punya padanan langsung, impor data yang berkonflik, lalu bangun ulang modelnya di Go. Ada satu fitur yang membuat saya bangga: pembaruan real-time antar aplikasi dengan LISTEN/NOTIFY bawaan PostgreSQL.2 Untuk itu, kami tidak perlu message broker tambahan; database-nya sendiri yang mengetuk pintu. Sedikit rakus, tapi rakus secara teknis hehe~

Lalu Arah Anginnya Berubah #

Sekitar setahun kemudian, arah angin berubah. Keputusannya: sistem warisan tetap memakai MySQL dan data domain utama kembali ke MySQL. PostgreSQL tidak dihapus, melainkan dialihkan ke tempat yang lebih cocok: data lokasi time-series, yang paling rakus dan paling membutuhkan partisi waktu.

Dari kacamata bisnis, keputusan itu masuk akal. Data yang sama tidak perlu dirawat di dua mesin dengan dua aturan, sementara sistem warisan masih bertahan jauh melampaui rencana siapa pun. Saya tidak mempermasalahkan logikanya.

Namun, biaya peralihannya mendarat di tempat yang sama: meja saya.

Aplikasi yang lahir dan tumbuh dengan dialek PostgreSQL tiba-tiba harus memakai dialek MySQL: sintaksnya berbeda, perilaku standard library SQL-nya berbeda, begitu juga nama dan perilaku tipenya. Error bermunculan di bagian yang sehari sebelumnya masih hijau. Optimasi LISTEN/NOTIFY yang sudah selesai? Menganggur. Saya pun mengerjakan ulang hal yang sama, dengan tangan yang sudah hafal jalan yang salah hehe~

Akhirnya, Dua Database #

Hasil akhirnya tampak seperti damai setelah duel: MySQL memegang data domain, PostgreSQL memegang data lokasi. Dua mesin, dua peran, tanpa saling mengganggu. Arsitektur ini tidak lahir dari gambar rapi di whiteboard. Ia terbentuk dari dua keputusan besar yang berbalik arah, sementara deployment harus tetap hidup di antaranya.

Kalau ditanya keputusan mana yang benar, saya rasa keduanya masuk akal pada waktunya. Yang bikin saya kapok adalah mengira arah arsitektur tidak akan berubah, lalu membangun semuanya tanpa rencana cadangan. Tagihannya saya bayar sendiri dalam bentuk kerja ulang hahaha.

Frontend-nya Juga Begitu #

Warisan yang tidak konsisten itu ternyata tidak berhenti di backend. Saat mulai menyentuh frontend v3, yang merupakan port tipis dari v2, saya mencium masalah lama dari sisi seberang: field dengan sumber yang berpindah-pindah, konvensi penamaan dari era yang berbeda, dan kode yang membuat saya, backend engineer biasa, bisa mencium bau spaghetti tanpa jago frontend hehe~

Mungkin itu cerita untuk seri lain. Yang ini sudah cukup panjang.

Catatan dari Epilog Ini #

  1. Pikirkan biaya pulangnya juga. Migrasi database bisa jadi perjalanan pulang-pergi kalau arah keputusan berubah.
  2. Fleksibilitas dialek SQL ada ongkosnya. Kalau ingin pindah mesin dengan mudah, hati-hati memakai fitur khasnya (iya, termasuk LISTEN/NOTIFY-ku). Kalau mau memakainya, ya jangan sekaligus menjanjikan semuanya gampang dipindah.
  3. Satu data, satu rumah. Dua mesin tidak masalah kalau perannya jelas. Yang bikin repot itu data yang tumpang tindih.
  4. Keputusan di atas gaji kita tetap harus dijalani. Setelah rapat selesai, sistemnya harus tetap hidup. Saya cuma berharap biaya perubahannya ikut dicatat hehe.

Nah, itu tadi adegan pasca-kreditnya. Terima kasih sudah ikut sampai sini. Semoga armada Anda, kalau punya, rajin mengirim kabar. Dan semoga mesin databasenya tidak mendadak pindah haluan hehe.


  1. Kutipan dan urutan kejadian disajikan dari ingatan dan catatan pribadi, dengan istilah teknis disederhanakan; nama pihak dan provider tidak disebut, konsisten dengan episode-episode sebelumnya. ↩︎

  2. Penjelasan singkat: LISTEN/NOTIFY adalah fitur PostgreSQL untuk mengirim sinyal antar aplikasi yang tersambung ke database yang sama. Praktis untuk live update; tidak berguna kalau aplikasinya pindah mesin. ↩︎