Cara Migrasi Database SQLite ke PostgreSQL

SQLite adalah pilihan awal yang benar untuk sangat banyak aplikasi: satu file, nol konfigurasi, cepat, dan jauh lebih tangguh dari reputasinya. Banyak sistem produksi hidup nyaman di atasnya bertahun-tahun. Tapi ada hari ketika ia mulai jadi hambatan — dan hari itu punya gejala yang jelas. Tutorial ini membantu Anda mengenali gejalanya, lalu memandu migrasi ke PostgreSQL dengan urutan yang aman: bukan "semoga lancar", melainkan dengan pengujian dan jalur mundur yang disiapkan sebelum melompat.

Tanda aplikasi Anda sudah melampaui SQLite

Pindah karena gejala, bukan karena gengsi:

• Banyak penulis serentak. SQLite mengunci penulisan di tingkat database; aplikasi dengan banyak proses yang menulis bersamaan mulai antre dan menjumpai error "database is locked".
• Lebih dari satu mesin butuh database yang sama. SQLite adalah file lokal; begitu ada server kedua, replika, atau alat otomasi yang menyambung dari luar, Anda butuh database berbentuk layanan.
• Kebutuhan fitur server: user dan hak akses berlapis, replikasi, connection pooling, tipe data lanjutan.

Kalau tidak satu pun terasa, berhentilah di sini dengan tenang — migrasi tanpa gejala hanyalah risiko tanpa hadiah.

Langkah 1: Petakan perbedaan tipe data dua database

Sumber kejutan migrasi nomor satu: SQLite longgar soal tipe (kolom INTEGER bisa saja berisi teks — ia tidak protes), PostgreSQL ketat. Sebelum apa pun, kenali titik rawannya: kolom tanggal yang di SQLite tersimpan sebagai teks bebas, angka yang tercampur string kosong, dan boolean yang tersimpan sebagai 0/1. Jalankan pemeriksaan cepat pada kolom-kolom penting (SELECT ... WHERE typeof(kolom) != 'integer' dan sejenisnya) untuk tahu seberapa kotor datanya — data kotor lebih murah dibersihkan sebelum pindah daripada didebug sesudahnya.

Langkah 2: Siapkan PostgreSQL tujuan

sudo apt install postgresql
sudo -u postgres createuser -P app_user
sudo -u postgres createdb -O app_user tokodb

Buat user aplikasi sendiri (bukan superuser postgres) sejak awal — kebiasaan hak-akses-secukupnya yang sama dengan yang kami tekankan di tutorial koneksi database. Pastikan aplikasi Anda kelak menyambung lewat user ini.

Langkah 3: Pindahkan skema dan data dengan pgloader

Alat terbaik untuk pekerjaan ini sudah ada dan matang: pgloader membaca file SQLite, membuat tabel-tabelnya di PostgreSQL dengan tipe yang diterjemahkan wajar, dan menyalin semua barisnya — satu perintah:

sudo apt install pgloader
pgloader ./data/app.db postgresql://app_user:PASSWORD@localhost/tokodb

Baca laporannya sampai selesai: pgloader mencetak jumlah baris per tabel dan error yang ia temui. Lalu verifikasi dengan mata sendiri — hitung baris beberapa tabel penting di kedua sisi dan cocokkan:

sqlite3 app.db "SELECT COUNT(*) FROM penjualan;"
psql -U app_user tokodb -c "SELECT COUNT(*) FROM penjualan;"

Periksa juga hasil terjemahan skema (tipe kolom, primary key, index) — pgloader menerjemahkan dengan baik, tapi keputusan akhirnya tetap tanggung jawab Anda. Kalau aplikasi Anda memakai ORM dengan sistem migrasi sendiri (Alembic, Prisma, Django), jalur yang lebih rapi: biarkan ORM membuat skema resminya di PostgreSQL, lalu pakai pgloader hanya untuk data (--with "data only").

Langkah 4: Uji aplikasi terhadap database baru

Arahkan aplikasi di lingkungan uji ke PostgreSQL (biasanya cukup mengganti connection string), lalu uji alur-alur nyatanya: buat transaksi, edit, cari, laporan. Titik yang paling sering patah dan patut dicek khusus: query dengan sintaks khas SQLite (fungsi tanggal seperti strftime, AUTOINCREMENT, perbandingan longgar angka-dengan-teks) dan asumsi urutan hasil tanpa ORDER BY. Setiap yang patah di sini adalah satu insiden produksi yang batal terjadi — itulah gunanya tahap ini, jangan memangkasnya.

Langkah 5: Rencanakan cutover dan jalur mundur

Migrasi sungguhan dilakukan saat trafik paling sepi, dengan urutan tertulis:

1. Hentikan aplikasi sebentar (umumkan jendela maintenance).
2. Jalankan pgloader sekali lagi dari file SQLite terkini — data yang masuk sejak uji coba ikut terbawa.
3. Simpan salinan file SQLite terakhir itu di tempat aman. Inilah jalur mundur Anda: kalau dalam beberapa jam pertama ada masalah serius, kembalikan connection string ke SQLite dan Anda kembali ke keadaan persis sebelum migrasi.
4. Arahkan aplikasi ke PostgreSQL, nyalakan, dan uji alur terpenting sekali lagi di produksi.
5. Hari-hari pertama: pantau log lebih rajin dari biasanya, dan tunda menghapus file SQLite lama setidaknya sampai beberapa siklus backup PostgreSQL yang teruji sudah berjalan.

Migrasi yang baik terasa membosankan — semua drama sudah dihabiskan di tahap uji. Kalau sistem Anda terlalu penting untuk bereksperimen sendiri, atau skemanya rumit oleh riwayat bertahun-tahun, tim software Clovertechno mengerjakan migrasi seperti ini sebagai pekerjaan rutin — ceritakan kondisi database Anda dan kami petakan jalurnya.