- Infisical berkembang pesat sebagai platform yang memproses lebih dari 50 juta Secret per hari
- Seiring meningkatnya penggunaan, mereka harus terus meng-upgrade stack, dan baru-baru ini melakukan migrasi seluruh database dari MongoDB ke PostgreSQL
- Migrasi ini mencakup proses kompleks seperti adopsi teknologi baru, pembuatan skema database, rekonstruksi logika, penulisan ulang kueri, dan pemindahan jutaan (atau puluhan miliar) record data ke PostgreSQL
Tahap awal
- Saat pertama kali membangun Infisical, tim memilih MongoDB + Mongoose ORM dengan menggunakan stack yang paling familier bagi mereka
- Pada awalnya, mereka lebih fokus pada Infisical Cloud, penawaran SaaS terkelola, dan tidak terlalu memperkirakan banyak pengguna akan melakukan self-hosting produk
Mengapa bukan MongoDB?
- MongoDB bekerja dengan baik pada awalnya, tetapi ketika use case produk melampaui layanan terkelola, kekurangannya mulai terlihat
- Banyak organisasi lebih memilih melakukan self-hosting Infisical daripada menggunakan Infisical Cloud, dan sebagian harus memenuhi kebutuhan on-premise
- Karena keterbatasan dan masalah kegunaan MongoDB, mereka memutuskan beralih ke PostgreSQL
Mengapa memilih PostgreSQL?
- Saat mencari database baru, kemudahan pengelolaan, dukungan transaksi, dan fitur relasional menjadi faktor penting
- Mereka sempat mempertimbangkan antara solusi penyimpanan internal dan eksternal, tetapi akhirnya memilih PostgreSQL
- PostgreSQL memiliki komunitas yang aktif, dokumentasi yang kaya, beragam solusi dan ekstensi, serta layanan terkelola yang disediakan oleh sebagian besar penyedia cloud
Tentang ORM
- Setelah memilih PostgreSQL, mereka perlu menentukan cara aplikasi berinteraksi dengan database
- Mereka mencari alat yang memberikan pengalaman serupa dengan Mongoose ORM, lalu memutuskan menggunakan query builder Knex.js
- Knex.js menyediakan alat seeding dan migrasi, dan lewat integrasi Zod kustom untuk dukungan TypeScript, mereka mencapai tingkat kepuasan yang memadai
Rencana migrasi
- Menjelang selesainya penulisan ulang kode, mereka memikirkan bagaimana menjalankan migrasi yang memetakan data MongoDB ke PostgreSQL dengan gangguan seminimal mungkin
- Untuk Infisical yang berperan dalam infrastruktur penting, downtime sama sekali tidak bisa diterima, sehingga mereka berkompromi dengan melarang operasi tulis selama masa migrasi
Perpindahan besar
- Untuk persiapan migrasi, mereka membuat checklist yang rinci dan jadwal waktu yang diperkirakan
- Migrasi dilakukan selama 6 jam dengan hanya mengizinkan operasi baca, lalu setelah pemindahan data selesai DNS dialihkan ke instance baru
Hasil
- Migrasi berjalan lancar tanpa kehilangan data, dan beberapa bug fitur dengan dampak minimal terhadap pelanggan diperbaiki dalam 36 jam
- Platform mengalami peningkatan performa berkat optimasi kueri melalui join, dan biaya database juga turun 50%
- Dengan adopsi PostgreSQL, validasi data membaik dan kini self-hosting Infisical menjadi jauh lebih mudah
Kesimpulan
- Keputusan untuk berpindah dari MongoDB ke PostgreSQL bukanlah hal mudah, dan memerlukan 3–4 bulan melalui perencanaan serta diskusi yang cermat
- Mereka merekomendasikan untuk memikirkan use case dan implementasi secara mendalam sebelum mencoba proyek besar seperti ini
1 komentar
Komentar Hacker News
Seorang pengguna yang berpengalaman mengoperasikan Postgres dan MongoDB dalam skala besar mengatakan ia menyukai kedua database tersebut, tetapi tidak bisa memahami kurangnya dukungan ketersediaan tinggi (HA) dan penskalaan horizontal di Postgres. Ia menyoroti bahwa setiap instalasi Postgres selalu unik, dan hal itu harus ditambal dengan berbagai ekstensi serta skrip. Ia menambahkan bahwa ekstensi-ekstensi ini sering kali penuh bug dan dokumentasinya kurang memadai. Ia juga menyebut perubahan format file pada versi mayor Postgres membuat upgrade menjadi sangat sulit. Ia heran MySQL jauh lebih baik daripada Postgres dalam hal HA/sharding.
Ia membagikan sebuah posting blog yang menjelaskan pengalaman migrasi dari MongoDB ke PostgreSQL dari sudut pandang teknis. Disebutkan bahwa posting ini lebih teknis dan lebih sedikit membahas sisi bisnis, serta menyertakan contoh dan grafik.
Seorang pengguna yang mengatakan PostgreSQL sedang menguasai dunia database menunjukkan bahwa para penulis sejak awal memilih arsitektur yang tidak cocok dengan model datanya. Ia menyebut bahwa menaruh data relasional ke dalam penyimpanan non-relasional akan selalu menimbulkan masalah.
Ia menyoroti kontradiksi antara kalimat yang menyatakan bahwa memilih MongoDB dan ORM Mongoose adalah keputusan yang dioptimalkan untuk mempercepat pengembangan fitur, dan kalimat yang membenarkan pilihan itu dengan kutipan Tony Hoare, "optimisasi prematur adalah akar dari segala kejahatan".
Seorang pengguna yang menganggap database dokumen tidak cocok untuk proyek baru memperkirakan biaya lisensi dan hosting MongoDB akan meningkat, sementara pengembangan fiturnya akan mandek.
Seorang pengguna yang pernah beralih ke Postgres karena masalah yang disebabkan MongoDB mengatakan ia sangat puas dengan keputusan tersebut. Ia menambahkan bahwa penggunaan JavaScript alih-alih SQL di MongoDB terasa tidak nyaman.
Seorang pengguna menunjukkan bahwa pembahasan tentang masalah yang terjadi selama proses rewrite yang sebenarnya tidak ada. Ia mengajukan pertanyaan tentang apakah query dibuat setara, bagaimana produk dikonfigurasi agar bisa membaca dan menulis ke kedua database, apakah bug ditemukan selama migrasi, dan apakah query bisa dipindahkan secara 1:1.
Seorang pengguna yang pernah memakai MongoDB mengatakan database dokumen memang cocok untuk beberapa use case, tetapi saat menyadari harus menggunakan Mongoose, itulah saatnya mempertimbangkan beralih ke database relasional. Ia menyarankan bahwa dalam kebanyakan kasus Mongoose perlu ditambahkan ke proyek yang sudah ada; jika sejak awal sudah dibutuhkan, sebaiknya gunakan database relasional.
Seorang pengguna yang mewarisi proyek yang menggunakan MongoDB mengatakan format BSON kurang bagus, tetapi ia menyukai bahwa skema yang sama bisa digunakan dari JSON API hingga database. Ia menambahkan ini cocok untuk pemrograman berorientasi data di Go dan Rust. Ia menyimpulkan MongoDB hanya cocok untuk beban kerja yang dominan baca, dan untuk beban tulis yang tinggi MongoDB tidak terlalu membantu.
Seorang pengguna yang mengatakan alasan utama beralih ke PostgreSQL adalah masalah lisensi, bukan alasan teknis, membagikan bahwa ia mengalami peningkatan performa berkat optimisasi query menggunakan join. Ia menyebut bahwa karena datanya tidak dimodelkan agar cocok untuk key-value store, beralih ke jenis penyimpanan yang tepat menjadi alasan yang menentukan.