PostgreSQL vs SQL Server untuk Alat Internal dan Backend SaaS

Masalah yang Anda selesaikan dengan pilihan database

Alat internal dan backend SaaS sering terlihat mirip di awal: formulir, tabel, pencarian, peran, dan banyak layar buat-baca-perbarui-hapus. Pilihan database menentukan apakah itu tetap sederhana atau berubah menjadi pembersihan konstan.

Alat internal biasanya butuh iterasi cepat, izin yang jelas, impor dan ekspor yang andal, serta performa stabil untuk kueri sehari-hari. Backend SaaS menambah tekanan dari banyak tenant, ekspektasi uptime lebih tinggi, jejak audit yang lebih jelas, migrasi yang lebih aman, dan pertumbuhan yang tidak seharusnya memaksa penulisan ulang.

Aplikasi berat-CRUD bisa terasa bagus di awal karena dataset kecil, trafik ringan, dan hampir semua kueri bekerja. Rasa sakit muncul nanti ketika banyak hal terjadi bersamaan: lebih banyak edit simultan, tabel membesar, layar “filter berdasarkan semua hal”, dan pekerjaan latar seperti email, penagihan, dan sinkronisasi. Pada titik itu, indexing, rencana kueri, dan disiplin operasional lebih penting daripada skema yang Anda buat di minggu pertama.

Beberapa pilihan sulit dibatalkan setelah Anda berkomitmen. Lisensi dan pengadaan bisa membatasi apa yang boleh Anda deploy. Keterampilan tim penting karena butuh seseorang yang mendukungnya saat tekanan. Tooling dan integrasi (ETL, BI, backup, monitoring) menentukan kelancaran pekerjaan harian. Fitur spesifik platform bisa menciptakan lock-in. Dan migrasi menjadi lebih sulit saat skema dan data tumbuh.

Cara sederhana memandang PostgreSQL vs SQL Server adalah memperlakukannya sebagai empat keputusan: biaya, operasi, pelaporan, dan jebakan skala. Anda tidak perlu jawaban sempurna untuk keempatnya, tetapi Anda harus tahu mana yang paling penting untuk aplikasi Anda.

Contoh: Anda membangun dashboard operasi di AppMaster, rilis secara internal, lalu memproduksi untuk pelanggan. Setelah menambahkan pelaporan per-pelanggan, ekspor terjadwal, dan puluhan orang menjalankan filter “90 hari terakhir” bersamaan, database berhenti menjadi kotak centang dan menjadi bagian dari cerita keandalan Anda.

Ringkasan praktis cepat: kapan masing-masing cocok

Jika Anda butuh cek cepat soal PostgreSQL vs SQL Server, mulailah dari tim Anda, batasan hosting, dan seperti apa “selesai” dalam enam bulan.

PostgreSQL adalah default umum bagi tim yang membangun backend SaaS baru. Ia tersedia luas di berbagai cloud, mendukung standar dengan baik, dan menawarkan banyak kemampuan tanpa negosiasi edisi. Ia juga cocok saat portabilitas penting, saat Anda ingin lingkungan ramah container, atau saat Anda mengandalkan layanan database terkelola.

SQL Server sering unggul di organisasi yang heavily Microsoft di mana Windows, Active Directory, dan stack BI sudah bagian operasi sehari-hari. Jika pipeline pelaporan Anda bergantung pada tooling Microsoft, atau DBA Anda sudah ahli SQL Server, biaya orang dan proses bisa lebih rendah meski biaya software tidak.

Sebagian besar jawaban “tergantung” bermuara pada batasan. Ini biasanya menyelesaikan pilihan dengan cepat: apa yang tim Anda bisa operasikan dengan percaya diri, apa yang pengadaan dan kepatuhan izinkan, ekosistem mana yang sudah Anda pakai, layanan terkelola apa yang ada di wilayah target, dan apakah beban kerja Anda kebanyakan trafik CRUD atau pelaporan lintas-tim yang berat.

Penawaran database terkelola mengubah tradeoff. Backup, patching, dan failover jadi kurang menyakitkan, tetapi Anda masih membayar dalam bentuk lain: biaya, batasan, dan kontrol tuning yang berkurang.

Skenario konkret: tim operasi kecil membangun alat tiket internal yang kemudian menjadi portal pelanggan. Jika mereka membangun dengan platform no-code seperti AppMaster dan ingin deployment mudah di berbagai cloud, PostgreSQL sering jadi pilihan nyaman. Jika perusahaan yang sama sudah menjalankan monitoring dan pelaporan SQL Server yang distandarisasi dan hidup dalam lisensi Microsoft, SQL Server bisa jadi pilihan yang lebih aman bahkan untuk produk baru.

Lisensi dan total biaya: apa yang benar-benar Anda bayar

Saat orang membandingkan PostgreSQL vs SQL Server, perbedaan harga jarang hanya “gratis vs berbayar.” Biaya nyata muncul pada inti CPU, lingkungan, ekspektasi dukungan, dan berapa banyak salinan database yang perlu Anda jalankan dengan aman.

Biaya SQL Server didorong oleh lisensi. Banyak tim membayar per core, dan edisi yang Anda pilih menentukan batasan dan fitur. Tagihan sering meningkat ketika Anda pindah ke mesin yang lebih besar, menambah CPU untuk beban puncak, atau menstandarisasi pada edisi yang lebih tinggi untuk kebutuhan availability dan keamanan.

PostgreSQL tidak punya biaya lisensi, tetapi bukan berarti nol biaya. Anda masih membayar hosting, storage, backup, dan respons insiden. Anda juga membayar waktu: waktu tim Anda untuk menjalankannya atau premi untuk layanan terkelola. Jika tim Anda sudah tahu Postgres (atau Anda memilih layanan terkelola), ini cenderung bisa diprediksi. Jika tidak, beberapa bulan pertama bisa lebih mahal dari perkiraan.

Biaya berubah cepat saat Anda menambah replika, high availability, atau banyak lingkungan. Bermanfaat untuk membuat daftar semua tempat database akan hidup: produksi plus failover, replika baca untuk dashboard, staging dan test yang mencerminkan produksi, pemisahan per-pelanggan untuk kepatuhan, dan pemulihan bencana di region kedua.

Item garis tersembunyi seringkali menentukan pemenang. Anggarkan untuk dukungan, penyimpanan backup dan pengujian restore, monitoring dan alerting, serta kebutuhan audit seperti retensi log dan review akses. Peralihan umum terjadi ketika alat internal berat-CRUD berubah menjadi aplikasi SaaS dan tiba-tiba membutuhkan kontrol akses lebih ketat, restore yang andal, dan alur rilis yang lebih aman. Tool seperti AppMaster dapat mempercepat pembangunan aplikasi, tetapi Anda tetap ingin menganggarkan dan merencanakan database sebagai sesuatu yang berjalan 24/7.

Beban operasional: menjalankannya tanpa terbangun jam 2 pagi

Kebanyakan tim meremehkan berapa banyak pekerjaan sehari-hari yang dibutuhkan database setelah pengguna dan data nyata datang. Dalam debat PostgreSQL vs SQL Server, nuansa operasional seringkali lebih penting daripada satu fitur pun.

Di kedua database, tugas inti sama: backup, restore, patching, dan upgrade. Perbedaannya biasanya pada tooling dan kebiasaan. SQL Server cenderung cocok secara mulus di lingkungan berpusat Microsoft, di mana banyak tugas dipandu dan distandarisasi. PostgreSQL sama kemampuannya, tetapi sering menuntut Anda membuat lebih banyak pilihan (pendekatan backup, stack monitoring, metode upgrade). Itu bisa jadi bagus atau menyebalkan tergantung tim Anda.

Tugas yang paling sering menggigit tim sederhana, tetapi mudah ditunda: membuktikan restore benar-benar bekerja, merencanakan upgrade versi di sekitar downtime atau jendela read-only, menjaga indeks tetap sehat saat tabel tumbuh, memantau jumlah koneksi dan pengaturan pool, serta mengatur alert untuk penggunaan disk, lag replikasi, dan kueri lambat.

High availability dan failover jarang gratis. Keduanya bisa melakukannya, tetapi Anda tetap harus memutuskan siapa yang dipaging, bagaimana Anda menguji failover, dan bagaimana aplikasi berperilaku selama itu (retry, timeout, dan penulisan idempotent). Layanan terkelola mengurangi pekerjaan setup, tetapi tidak menghapus kepemilikan.

Migrasi semakin sulit seiring data tumbuh

Perubahan skema yang terasa instan pada 10.000 baris bisa berubah menjadi penguncian panjang pada 100 juta. Kemenangan operasional biasanya datang dari proses, bukan merek: jadwalkan jendela, jaga perubahan kecil, dan latih rollback. Bahkan dengan platform no-code, Anda tetap perlu rencana bagaimana pembaruan model data mencapai produksi dan bagaimana memverifikasinya menggunakan backup nyata.

Keterampilan tim mengubah risiko

Dengan DBA khusus atau pengalaman database yang kuat, salah satu pilihan bisa berjalan tenang. Jika operasional dipimpin oleh pengembang, pilih apa yang sesuai dengan alat sehari-hari dan kenyamanan hosting tim Anda. Buat runbook sesederhana mungkin sehingga seseorang bisa mengikutinya setengah mengantuk.

Pelaporan dan analitik: kekuatan dan hambatan umum

Pelaporan biasanya campuran pertanyaan ad hoc, dashboard yang sering refresh, dan ekspor yang dijalankan seseorang tepat sebelum rapat. Bacaan ini bisa tak terduga dan berat, dan bisa bersaing dengan trafik CRUD.

Baik PostgreSQL maupun SQL Server mampu menangani join kompleks, fungsi window, dan agregasi besar. Perbedaan yang paling terasa adalah tuning dan tooling pendukung. Ekosistem pelaporan SQL Server jadi nilai tambah saat perusahaan Anda sudah menjalankan tool Microsoft. PostgreSQL juga punya fitur kuat, tetapi Anda mungkin lebih bergantung pada tool BI dan pekerjaan kueri serta index yang hati-hati.

Aturan praktis untuk keduanya: buat kueri jadi membosankan. Filter sejak awal, kembalikan lebih sedikit kolom, dan tambahkan index yang tepat untuk filter dan kunci join yang benar-benar Anda pakai. Di PostgreSQL, itu sering berarti index komposit yang baik dan memeriksa rencana kueri. Di SQL Server, biasanya index ditambah stats, dan kadang columnstore untuk scan ala analitik.

Pola pelaporan umum yang membebani database OLTP meliputi dashboard yang refresh terlalu sering dengan full-table scan, pekerjaan “ekspor semuanya” saat jam kerja, join lebar dan sort di banyak tabel besar, scanning tabel event untuk total alih-alih rollup, dan filter ad hoc yang mematahkan index (mis. wildcard di awal).

Jika pelaporan mulai memperlambat aplikasi, sering kali saatnya memisahkan kepentingan. Anda tidak perlu program data raksasa untuk itu.

Pertimbangkan database pelaporan atau warehouse terpisah ketika laporan harus tetap cepat selama penulisan puncak, Anda butuh kueri lama yang tidak boleh memblokir produksi, Anda bisa menerima data tertunda beberapa menit, atau Anda ingin tabel pra-agregasi untuk metrik umum.

Jika Anda membangun alat internal atau backend SaaS di AppMaster, rencanakan ini sejak awal: jaga tabel transaksional tetap bersih, tambahkan tabel ringkasan sederhana di tempatnya, dan jadwalkan ekspor atau job sinkronisasi sehingga pelaporan tidak bersaing dengan trafik CRUD langsung. Keputusan ini sering lebih penting daripada label database yang Anda pakai.

Model data dan fitur yang penting di aplikasi berat-CRUD

Aplikasi berat-CRUD terlihat sederhana di kertas, tetapi pilihan model data awal menentukan seberapa baik Anda menangani pertumbuhan, retry, dan banyak pengguna yang menekan Save bersamaan. Di sinilah pengalaman pengembang sehari-hari juga bisa mempengaruhi keputusan PostgreSQL vs SQL Server.

Primary key adalah contoh bagus. ID integer ringkas dan ramah index, tetapi bisa membuat hotspot saat beban insert tinggi. UUID menghindari pola selalu meningkat dan cocok untuk klien offline-friendly dan penggabungan data nanti, tetapi membutuhkan lebih banyak penyimpanan dan membuat index lebih besar. Jika memilih UUID, rencanakan ukuran index tambahan dan gunakan konsisten di seluruh tabel agar join tetap dapat diprediksi.

Concurrency adalah mode kegagalan senyap lainnya. Banyak alat internal dan backend SaaS menjalankan banyak transaksi pendek: baca baris, ubah status, tulis record audit, ulangi. Risikonya sering pola locking yang menumpuk saat puncak. Jaga transaksi singkat, perbarui dalam urutan stabil, dan tambahkan index yang membantu update menemukan baris dengan cepat.

Data semi-terstruktur sekarang normal, apakah itu pengaturan per-pelanggan atau payload event. Kedua database bisa menangani penyimpanan gaya JSON, tetapi perlakukan itu sebagai alat, bukan tempat sampah. Simpan field yang Anda filter sebagai kolom nyata, dan gunakan JSON untuk bagian yang sering berubah.

Pemeriksaan cepat sebelum berkomitmen:

• Apakah Anda sebagian besar memfilter berdasarkan beberapa field saja, atau perlu pencarian di teks dan metadata?
• Apakah Anda butuh pengaturan per-pelanggan yang fleksibel dan sering berubah?
• Apakah akan ada banyak penulis sekaligus (tim dukungan, otomatisasi, klien API)?
• Apakah Anda berharap menambahkan log audit, event, atau tabel history dengan cepat?

Jika Anda membangun alat internal dengan pemodel visual (mis. Data Designer AppMaster menargetkan PostgreSQL), pilihan tersebut tetap penting. Skema yang dihasilkan akan mencerminkan tipe kunci, index, dan penggunaan JSON Anda.

Langkah demi langkah: cara memilih untuk aplikasi Anda (tanpa overthinking)

Memilih antara PostgreSQL vs SQL Server lebih mudah ketika Anda berhenti berdebat soal fitur dan mulai mengukur beban kerja. Anda tidak perlu perkiraan sempurna. Anda butuh beberapa angka dan cek realitas.

Alur keputusan sederhana

1. Estimasikan pertumbuhan dengan istilah sederhana. Berapa banyak baris akan mencapai tabel terbesar Anda dalam 12 bulan? Berapa laju tulis steady, concurrency puncak, dan tipe kueri teratas?
2. Pilih model hosting dulu. Jika Anda ingin kerja sehari-hari lebih sedikit, anggap menggunakan database terkelola. Jika harus self-host, jujurlah siapa yang akan patch, tune, dan tangani insiden.
3. Tetapkan baseline untuk keselamatan. Definisikan frekuensi backup, retensi, dan target RPO/RTO. Putuskan apa yang akan Anda tinjau mingguan: pertumbuhan disk, kueri lambat, lag replikasi, dan saturasi koneksi.
4. Jalankan proof kecil dengan data nyata. Impor sampel realistis dan uji beberapa kueri yang akan sering dipakai, plus tes tulis yang meniru lonjakan, bukan rata-rata.
5. Putuskan dengan scorecard sederhana. Pilih opsi yang bisa Anda jalankan dengan baik, bukan yang menang dalam debat teoritis.

Setelah bukti, buat scorecard yang mudah dijelaskan:

• Total biaya (lisensi, tier managed, penyimpanan backup)
• Keterampilan tim (apa yang tim Anda bisa dukung tanpa aksi heroik)
• Performa untuk kueri nyata Anda (bukan benchmark generik)
• Kepatuhan dan kebutuhan keamanan (kontrol akses, audit)
• Kecocokan operasional (monitoring, upgrade, respon insiden)

Jika Anda membangun alat internal di AppMaster, model database Anda biasanya PostgreSQL-first. Itu bisa jadi default kuat, selama bukti Anda menunjukkan kueri utama dan lonjakan tulis tetap sehat sesuai beban yang diharapkan.

Kesalahan umum dan jebakan skala yang harus dihindari

Perangkap terbesar dalam keputusan PostgreSQL vs SQL Server adalah mengasumsikan database akan tetap “kecil dan ramah” selamanya. Sebagian besar kegagalan datang dari kebiasaan yang bisa dihindari yang baru terlihat saat aplikasi populer dan data berantakan.

Pengaturan default jarang siap produksi. Cerita khas: staging terlihat baik, lalu spike pertama datang dan Anda melihat kueri lambat, timeout, atau pertumbuhan disk tak terkendali. Rencanakan lebih awal untuk backup, monitoring, dan batas yang masuk akal untuk memori dan kerja paralel.

Pelaporan adalah sumber masalah umum lain. Tim menjalankan dashboard berat pada database yang sama yang menangani penulisan kritis, lalu heran kenapa aksi CRUD terasa lambat. Jaga pelaporan terkendali, terjadwal, atau terpisah sehingga tidak mencuri sumber daya dari penulisan.

Kesalahan indexing dua arah. Kekurangan index membuat daftar dan pencarian melambat. Terlalu banyak index membengkakkan storage dan membuat insert/update mahal. Gunakan pola kueri nyata Anda, lalu tinjau index seiring aplikasi berubah.

Manajemen koneksi adalah masalah “bekerja sampai tidak”. Ukuran pool yang baik untuk alat internal bisa runtuh saat Anda menambah job latar, lebih banyak trafik web, dan tugas admin. Waspadai lonjakan koneksi, sesi idle panjang, dan retry.

Kebiasaan skala yang harus dihindari:

• Satu tabel raksasa yang mencampur data tak terkait karena terasa lebih sederhana
• Satu transaksi besar yang memperbarui semuanya “untuk aman”
• Mengizinkan kueri ad hoc tanpa timeout atau batas
• Menambahkan index untuk setiap kolom tanpa pengukuran
• Mengabaikan slow query log sampai pengguna mengeluh

Contoh: alat dukungan kecil menjadi backend SaaS. Halaman analitik baru menjalankan filter lebar selama berbulan-bulan tiket sementara agen terus memperbarui tiket sepanjang hari. Perbaikan biasanya tidak dramatis: tambahkan index yang tepat, batasi kueri analitik, dan pisahkan beban kerja pelaporan.

Jika Anda membangun dengan platform seperti AppMaster, perlakukan backend yang dihasilkan sama. Ukur kueri nyata, tetapkan batas aman, dan jaga agar pelaporan tidak bersaing dengan penulisan inti.

Daftar periksa cepat sebelum berkomitmen (atau sebelum Anda skala)

Jika Anda hanya melakukan satu hal sebelum memilih database, lakukan ini: pastikan Anda bisa pulih dengan cepat, dan pastikan performa di bawah beban nyata Anda. Sebagian besar debat PostgreSQL vs SQL Server melewatkan bahwa bagian menyakitkan muncul belakangan.

Pemeriksaan keandalan dan operasi

Jangan percaya centang hijau. Jalankan tes restore nyata ke lingkungan bersih dan validasi aplikasi bisa baca dan tulis. Waktu end-to-end, dan tuliskan langkah yang bisa diulang orang lain.

Pasang monitoring dasar sejak awal: ruang disk bebas, laju pertumbuhan per minggu, dan ambang alert. Masalah storage sering terlihat hanya setelah penulisan mulai gagal.

Pemeriksaan performa dan skala

Lakukan pemeriksaan cepat pada kueri sebelum Anda skala. Tangkap kueri lambat teratas Anda (yang paling sering dijalankan, bukan hanya kueri terburuk satu kali) dan lacak dari waktu ke waktu.

Checklist singkat:

• Backup: jalankan tes restore terverifikasi, bukan sekadar “backup berhasil”
• Indexes: identifikasi dan lacak 10 kueri lambat teratas
• Koneksi: set dan monitor batas pool saat trafik puncak
• Storage: alert pada ruang bebas dan laju pertumbuhan
• Perubahan skema: rencanakan migrasi untuk tabel besar (jendela waktu dan rollback)

Tetapkan aturan jelas untuk pelaporan. Jika seseorang bisa klik Ekspor dan memicu kueri besar pada database yang sama yang melayani CRUD, itu akan berdampak. Putuskan di mana export dan kueri dashboard berat berjalan, bagaimana batasnya, dan seperti apa perilaku timeout.

Jika Anda membangun alat internal cepat (mis. dengan AppMaster), anggap cek ini sebagai bagian dari “done” untuk tiap rilis, bukan sesuatu yang ditunda.

Contoh skenario: mengubah alat internal menjadi backend SaaS

Jalur umum seperti ini: Anda mulai dengan dashboard dukungan untuk agen, workflow tiket (status, penugasan, SLA), dan portal pelanggan sederhana di mana pengguna bisa membuat dan melihat tiket. Awalnya internal, lalu Anda menambahkan login pelanggan, lalu penagihan, dan perlahan menjadi SaaS.

Bulan 0-3: data kecil, fitur cepat

Di awal, hampir setup apa pun terasa baik. Anda punya beberapa tabel (users, tickets, comments, attachments), pencarian dasar, dan beberapa ekspor untuk manajer.

Pada tahap ini, kemenangan terbesar adalah kecepatan rilis. Jika Anda memakai platform no-code seperti AppMaster untuk cepat mengirim UI, logika bisnis, dan API, pilihan database Anda paling mempengaruhi kemudahan hosting dan prediktabilitas biaya.

Sekitar bulan ke-12: yang mulai rusak

Saat penggunaan tumbuh, rasa sakit jarang “database lambat” dan lebih sering “satu hal lambat memblokir semuanya.” Masalah tipikal termasuk CSV besar yang timeout, kueri berat yang mengunci baris dan membuat pembaruan tiket terasa lambat, perubahan skema yang kini butuh jendela downtime, dan kebutuhan yang tumbuh untuk jejak audit, kontrol peran, dan aturan retensi. Trafik OLTP (tiket) juga mulai bersaing dengan trafik analitik (dashboard).

Di titik ini PostgreSQL vs SQL Server terasa berbeda secara praktis. Dengan SQL Server, tim sering mengandalkan tooling built-in matang untuk pelaporan dan monitoring, tetapi keputusan lisensi dan edisi menjadi lebih tajam saat menambah replika, HA, atau core. Dengan PostgreSQL, biaya seringkali lebih sederhana, tetapi Anda mungkin menghabiskan lebih banyak waktu memilih dan menstandarisasi pendekatan backup, monitoring, dan pelaporan.

Jalur realistis adalah menjaga database utama fokus pada tiket dan trafik portal, lalu pisahkan pelaporan. Itu bisa berupa replika baca, salinan terjadwal ke store pelaporan, atau database pelaporan khusus yang diisi setiap malam. Intinya adalah menjaga ekspor dan dashboard agar tidak bersaing dengan kerja dukungan langsung.

Langkah selanjutnya: buat keputusan dan kirim dengan risiko lebih kecil

Pilihan yang baik antara PostgreSQL vs SQL Server kurang tentang memilih “database terbaik” dan lebih tentang menghindari kejutan setelah peluncuran. Pilih default yang masuk akal, uji bagian yang bisa rusak, dan siapkan diri untuk menjalankannya dengan tenang.

Mulailah dengan menuliskan batasan nyata Anda: anggaran bulanan (termasuk lisensi), siapa yang on-call, persyaratan kepatuhan, dan tempat Anda harus host (cloud, on-prem, atau keduanya). Tambahkan apa yang tim Anda sudah tahu. Opsi termurah di kertas bisa mahal jika tidak ada yang bisa menanganinya dengan cepat.

Berkomitmen pada satu jalur untuk 12–18 bulan ke depan, bukan selamanya. Migrasi mungkin dilakukan nanti, tetapi beralih di tengah pembangunan itu menyakitkan. Tujuannya adalah kirim, pelajari dari penggunaan nyata, dan hindari rewrite saat Anda masih mencari kecocokan.

Rencana sederhana yang mencegah sebagian besar momen “seharusnya kita tahu”:

• Pilih 3–5 endpoint nyata (layar CRUD umum dan satu laporan berat) dan daftar kueri persis yang dijalankan.
• Buat benchmark kecil dengan ukuran data realistis dan beberapa level concurrency.
• Tulis rencana rollout untuk dev, staging, dan produksi, termasuk bagaimana perubahan skema dipromosikan.
• Putuskan seperti apa “sehat”: metrik kunci, alert kueri lambat, dan tingkat error yang dapat diterima.
• Latih backup dan restore sekali, sebelum Anda membutuhkannya.

Jika Anda membangun alat internal atau backend SaaS tanpa tim engineering besar, mengurangi kode kustom dapat mengurangi risiko. AppMaster (appmaster.io) dibuat untuk backend siap-produksi, web app, dan native mobile app, dan ia menghasilkan source code nyata sambil menjaga model data dan logika bisnis terorganisir dalam alat visual.

Akhiri dengan rencana pelaporan singkat (dashboard apa yang Anda butuh, siapa pemiliknya, dan seberapa sering mereka refresh). Lalu kirim versi kecil, ukur, dan iterasi.