SQLite vs Postgres: Kapan Memilih Database yang Mana

Dua Database, Dua Bentuk yang Berbeda

SQLite dan PostgreSQL sama-sama memakai SQL, sama-sama menyimpan data relasional, dan sama-sama bisa menjalankan aplikasi sungguhan. Selebihnya, keduanya dibuat untuk dunia yang berbeda.

• SQLite adalah library. Ia hidup di dalam proses aplikasimu dan membaca dari satu file .db di disk. Tidak ada server, tidak ada port, tidak ada user yang perlu dikonfigurasi.
• PostgreSQL adalah server. Ia berjalan sebagai proses tersendiri, mendengarkan di sebuah port jaringan, dan aplikasimu terhubung ke sana sebagai client.

Hampir semua perbedaan lain di antara keduanya (konkurensi, deployment, ketatnya tipe data, performa) berasal dari satu perbedaan arsitektur itu. Ingat hal ini sambil kita lanjut.

Arsitektur: Di Dalam Proses vs Client/Server

Membuka database SQLite sama dengan membuka file:

-- SQLite: the database is just this file.
CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT);
INSERT INTO notes (body) VALUES ('hello from a file');
SELECT * FROM notes;

Tidak ada daemon yang perlu dijalankan, tidak ada pg_hba.conf yang perlu diedit, tidak ada port yang perlu dibuka. Aplikasimu memuat library SQLite, membuka notes.db, lalu mulai menjalankan query. Deployment-nya cukup "salin file-nya."

Postgres kira-kira seperti ini:

# Start the server (once, as an admin):
sudo systemctl start postgresql

# Then connect from your app:
psql -h localhost -U alice -d mydb

Aplikasimu berkomunikasi dengan proses terpisah, biasanya lewat TCP, kadang lewat Unix socket. Lapisan tambahan itu membuatmu butuh waktu setup dan satu perjalanan bolak-balik koneksi untuk tiap query, tapi sebagai gantinya kamu mendapat akses jaringan, autentikasi multi-user, dan penulisan yang benar-benar serentak.

Konkurensi Adalah Faktor Terbesar

Biasanya inilah faktor penentunya. SQLite menjalankan penulisan satu per satu: pada satu waktu, hanya satu penulis yang memegang kunci pada file database, dan penulis lain menunggu. Pembacaan bisa berjalan paralel (terutama di mode WAL), tapi penulisan tetap bergiliran.

Postgres memakai MVCC (multi-version concurrency control) dan penguncian tingkat baris. Banyak transaksi bisa menulis ke baris yang berbeda secara bersamaan tanpa saling menghalangi.

Dalam praktiknya:

• Blog dengan 50 pembaca per detik dan satu penulis yang sesekali menulis? SQLite cukup.
• Checkout e-commerce tempat ratusan user memperbarui stok sekaligus? Postgres.
• Cache lokal di aplikasi mobile? SQLite, tanpa perlu dipikir lagi.
• Backend SaaS multi-tenant dengan puluhan background worker? Postgres.

Mode WAL (PRAGMA journal_mode = WAL;) membuat konkurensi SQLite jauh lebih baik, karena pembaca tidak menghalangi penulis, tapi aturan satu penulis dalam satu waktu tetap berlaku.

Sistem Tipe: Longgar vs Ketat

Postgres itu ketat. Kolom yang dideklarasikan INTEGER menolak string, titik:

-- Postgres
CREATE TABLE t (n INTEGER);
INSERT INTO t (n) VALUES ('not a number');
-- ERROR: invalid input syntax for type integer

Secara default, SQLite memakai type affinity, yaitu saran, bukan aturan. Insert yang sama berhasil:

CREATE TABLE t (n INTEGER);
INSERT INTO t (n) VALUES ('not a number');
SELECT n, typeof(n) FROM t;

String itu tetap ada di kolom INTEGER. SQLite menyimpannya sebagai teks. Fleksibilitas ini adalah pilihan desain yang disengaja: berguna untuk prototipe cepat, berbahaya untuk skema yang dipakai lama.

SQLite modern (3.37+) mendukung tabel STRICT yang perilakunya lebih mirip Postgres:

CREATE TABLE t (n INTEGER) STRICT;
-- INSERT INTO t (n) VALUES ('not a number');  -- now an error
INSERT INTO t (n) VALUES (42);
SELECT n, typeof(n) FROM t;

Kalau kamu memulai proyek SQLite baru, pakai STRICT. Ini menghilangkan satu golongan kejutan seperti "kenapa ada string di kolom angkaku".

Cakupan Fitur

Postgres punya lebih banyak hampir dalam segala hal: tipe data (array, range, geometri, jaringan, enum kustom), bahasa prosedural (PL/pgSQL, PL/Python), pencarian teks penuh dengan peringkat, materialized view, partisi tabel, replikasi, keamanan berbasis role, dan ekosistem ekstensi yang luas (PostGIS, TimescaleDB, pgvector).

SQLite mencakup hal-hal yang penting dan menambahkan beberapa fitur bagus untuk skalanya: fungsi JSON, pencarian teks penuh lewat FTS5, index R-Tree, window function, CTE, kolom generated. Yang tidak ada adalah apa pun yang mengandaikan adanya server: user, role, replikasi, akses jaringan.

Model mental kasarnya:

• Butuh GIS, pencarian vektor, atau replikasi? Postgres.
• Perlu menyertakan database di dalam aplikasi iOS? SQLite.
• Butuh keduanya? Banyak tim mengembangkan dan menguji dengan SQLite, lalu deploy di Postgres, meskipun campuran itu bisa merepotkan karena perbedaan sintaks (lihat di bawah).

Perbedaan Sintaks yang Benar-Benar Akan Kamu Temui

Sebagian besar SQL sehari-hari sama persis. Perbedaannya berkumpul di skema, tipe data, dan beberapa fungsi bawaan:

-- Auto-incrementing primary key
-- SQLite:
CREATE TABLE users (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT);
-- Postgres:
CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);
-- or, modern Postgres:
CREATE TABLE users (id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name TEXT);

-- Current timestamp
-- SQLite:  CURRENT_TIMESTAMP   (returns text)
-- Postgres: NOW()              (returns timestamp)

-- Boolean type
-- SQLite:  no real BOOLEAN; use INTEGER 0/1
-- Postgres: BOOLEAN with TRUE/FALSE

Kalau kamu mengembangkan di SQLite dan deploy di Postgres, ada baiknya memakai ORM atau alat migrasi di antara kamu dan SQL mentahnya. Kalau tidak, perbedaan-perbedaan ini akan bocor ke aplikasimu.

Performa, Apa Adanya

"Lebih cepat" bergantung pada pertanyaannya. Untuk satu proses yang membaca dan menulis dalam jumlah kecil, SQLite sulit dikalahkan: tidak ada lompatan jaringan, tidak ada parsing protokol, tidak ada koneksi client. Dalam benchmark dengan satu client, SQLite sering lebih cepat daripada Postgres untuk query sederhana.

Tambahkan penulis serentak, dataset besar yang butuh eksekusi query paralel, atau rencana query rumit yang diuntungkan oleh planner Postgres yang matang, dan Postgres pun memimpin. Postgres juga bisa diskalakan secara vertikal (mesin lebih besar, core lebih banyak) dengan cara yang memang tidak dirancang untuk SQLite.

Ringkasan jujurnya: SQLite cepat untuk tujuannya. Postgres cepat untuk tujuannya. Pilihlah berdasarkan bentuk beban kerja, bukan judul benchmark.

Panduan Singkat Memilih

Pilih SQLite saat:

• Datanya berada di samping satu aplikasi: desktop, mobile, perangkat tertanam, alat CLI.
• Penulisan datang dari satu proses atau sedikit proses.
• Kamu ingin deployment tanpa konfigurasi.
• Kamu sedang membuat prototipe dan ingin fokus pada skema, bukan infrastruktur.

Pilih Postgres saat:

• Beberapa server aplikasi atau worker menulis ke database.
• Kamu butuh akses jaringan dari banyak client.
• Kamu butuh fitur lanjutan: role, replikasi, GIS, tipe kustom, stored procedure.
• Datanya adalah penyimpanan pusat yang tahan lama untuk layanan produksi.

Jalur yang umum: mulai proyek kecil dengan SQLite, lalu pindah ke Postgres jika dan saat pola trafiknya menuntut. Migrasinya tidak gratis, tapi prosesnya sudah dikenal, dan sebagian besar proyek tidak pernah membutuhkannya.

Berikutnya: Saat SQLite Adalah Pilihan yang Tepat

Perbandingan di atas memberimu gambaran untung ruginya. Halaman berikutnya membahas lebih dalam alasan memilih SQLite: beban kerja yang membuatnya bukan sekadar cukup baik, tapi justru alat yang lebih tepat, dan tanda-tanda bahwa kebutuhanmu sudah melampauinya.