By Muhammad Rafli Akbar in Software Dev —

Database Traffic Control: Saat Postgres Butuh Rem Buat AI Agent

AI agent bisa membuat workload database lebih liar dari traffic manusia. Ini cara berpikir soal database traffic control, timeout, quota, dan guardrail Postgres yang realistis.

AI agent yang bisa query database itu keren… sampai satu query liar bikin Postgres lu ikut sesak napas.

Artikel ini membahas kenapa database traffic control mulai jadi topik penting di era AI agent, bukan cuma fitur enterprise yang jauh dari developer biasa. Intinya: kalau aplikasi lu memberi agent, job background, atau user power akses ke jalur yang sama menuju database, lu butuh rem, prioritas, dan batas kerja yang jelas. Bukan karena AI agent pasti buruk, tapi karena workload yang tidak dibatasi bisa mengubah bug kecil jadi incident produksi.

PlanetScale baru memperkenalkan Database Traffic Control untuk Postgres. Dari cara mereka memposisikan fitur ini, sinyalnya menarik: guardrail aplikasi tidak cukup berhenti di API layer. Beban paling mahal sering terjadi jauh di bawah, yaitu saat query menyentuh database, index, lock, CPU, memory, dan koneksi yang dipakai semua user.

Apa itu database traffic control?

Secara sederhana, database traffic control adalah cara mengatur lalu lintas query yang masuk ke database supaya workload tertentu bisa dibatasi, diprioritaskan, atau dihentikan sebelum merusak pengalaman user lain.

Kalau di dunia web lu sudah familiar dengan rate limit, WAF, queue, dan circuit breaker, konsep ini mirip. Bedanya, titik kontrolnya lebih dekat ke database. Tujuannya bukan sekadar “query boleh masuk atau tidak”, tapi juga menjawab pertanyaan yang lebih operasional:

  • Query mana yang harus diprioritaskan saat database mulai penuh?
  • Traffic user manusia dan traffic AI agent harus diperlakukan sama atau beda?
  • Job background boleh menghabiskan resource yang sama dengan request checkout user?
  • Query runaway harus dibunuh kapan?
  • Tenant berbayar dan tenant gratis punya budget workload yang sama atau tidak?

Di artikel PlanetScale, salah satu use case yang eksplisit disebut adalah isolasi traffic manusia dari traffic AI agent. Buat gua, ini bagian yang paling menarik, karena banyak pembahasan AI agent masih berhenti di prompt, tool permission, atau sandbox. Padahal begitu agent bisa memanggil tool yang menyentuh database, masalahnya berubah jadi reliability engineering.

Kenapa rate limit API belum cukup?

Rate limit di API tetap penting, tapi dia sering terlalu jauh dari biaya sebenarnya. Satu request API bisa murah, bisa juga sangat mahal. Contohnya:

  • GET /users/123 yang pakai primary key mungkin nyaris gratis.
  • GET /reports?range=all bisa memicu scan besar, join berat, atau aggregation panjang.
  • Satu prompt AI agent bisa menjalankan beberapa tool call beruntun, bukan cuma satu request.
  • Satu job background bisa membuat database sibuk walau traffic user kelihatan normal.

Jadi kalau lu cuma melihat jumlah request, lu bisa salah baca kondisi sistem. API kelihatan aman, tapi database sudah mulai antre. CPU naik, koneksi penuh, lock makin lama, lalu user biasa ikut kena dampaknya.

Masalahnya makin terasa saat AI agent masuk workflow. Agent tidak selalu punya intuisi “query ini mahal”. Dia bisa mencoba ulang, mengambil data terlalu luas, atau menjalankan eksplorasi yang masuk akal secara tujuan, tapi boros secara sistem. Kalau tool database lu terlalu bebas, agent bisa jadi user yang sangat rajin, sangat cepat, dan sangat tidak peka terhadap resource.

AI agent mengubah bentuk workload

Sebelum era agent, banyak aplikasi punya pola traffic yang relatif bisa ditebak: user klik tombol, browser panggil API, backend query database. Tetap bisa ada spike, tapi sumbernya cukup jelas.

Dengan AI agent, pola itu berubah. Agent bisa membaca konteks, memutuskan langkah berikutnya, lalu memanggil tool beberapa kali. Dalam skenario internal tool atau admin dashboard, agent mungkin diberi akses ke data yang lebih luas daripada user biasa. Ini produktif, tapi juga berisiko.

Beberapa contoh yang realistis:

  • Agent support customer ingin mencari histori transaksi, lalu query terlalu luas karena filter kurang spesifik.
  • Agent data analyst menjalankan eksplorasi berkali-kali untuk menjawab pertanyaan yang sebenarnya bisa dijawab dengan summary table.
  • Agent coding membuat migration atau script maintenance, lalu menjalankannya di environment yang salah.
  • Agent internal memanggil tool yang aman secara permission, tapi tetap mahal secara query cost.

Di sinilah bedanya boleh akses dan boleh menghabiskan resource. Auth menjawab “siapa lu dan boleh lihat apa”. Traffic control menjawab “seberapa banyak resource yang boleh lu pakai, kapan harus berhenti, dan siapa yang tetap harus dilayani saat sistem tertekan”.

Postgres sebenarnya sudah punya rem kecil

Lu tidak harus menunggu punya fitur enterprise dulu buat mulai berpikir seperti ini. Postgres sendiri sudah punya beberapa konfigurasi dasar yang bisa jadi rem awal, misalnya statement_timeout, lock_timeout, dan idle_in_transaction_session_timeout. Dokumentasi PostgreSQL menjelaskan ini sebagai bagian dari client connection defaults.

Versi sederhananya:

  • statement_timeout: batasi berapa lama sebuah query boleh berjalan.
  • lock_timeout: batasi berapa lama query boleh menunggu lock.
  • idle_in_transaction_session_timeout: matikan sesi yang diam terlalu lama di dalam transaksi.

Ini bukan pengganti arsitektur yang rapi, tapi cukup buat mencegah beberapa pola paling menyebalkan: query lupa filter, transaksi menggantung, atau proses internal yang tidak pernah selesai.

Kalau aplikasi lu mulai memberi AI agent akses ke tool database, minimal lu perlu punya boundary seperti ini. Jangan kasih agent koneksi superuser. Jangan kasih agent role yang sama dengan aplikasi utama kalau tidak perlu. Jangan biarkan tool query bebas tanpa timeout, limit, dan observability.

Checklist guardrail database buat era AI agent

Kalau lu sedang membangun internal tool, admin panel, workflow automation, atau AI agent yang bisa menyentuh database, ini checklist praktis yang bisa dipakai hari ini:

  1. Pisahkan role database. Role untuk user-facing app, background job, analytics, dan agent sebaiknya tidak semuanya satu identitas.
  2. Pasang timeout default. Query yang terlalu lama harus berhenti otomatis, bukan menunggu manusia sadar dari dashboard.
  3. Batasi hasil query. Tool agent sebaiknya punya pagination, limit, dan filter wajib untuk data besar.
  4. Bikin tool yang spesifik. Lebih aman memberi agent tool get_recent_orders(customer_id) daripada SQL bebas tanpa batas.
  5. Log tool call dan query cost. Minimal catat siapa/agent apa menjalankan tool, kapan, parameter apa, durasi berapa, dan hasilnya sukses atau gagal.
  6. Pakai read-only path jika cukup. Banyak kebutuhan agent hanya butuh baca data, bukan tulis data.
  7. Prioritaskan traffic manusia. Saat sistem tertekan, request user penting jangan kalah dari eksplorasi agent atau job batch.
  8. Siapkan tombol stop. Kalau agent mulai muter-muter, lu harus bisa memutus workload tanpa mematikan seluruh aplikasi.

Jangan jadikan traffic control alasan buat malas optimasi

Counterpoint penting: database traffic control bukan alasan buat mengabaikan query optimization. Kalau query lu tidak punya index, schema berantakan, dan report berat tetap dijalankan di database produksi utama, traffic control cuma jadi sabuk pengaman. Dia bisa mengurangi dampak, tapi bukan memperbaiki akar masalah.

Urutan yang lebih sehat menurut gua:

  1. Pahami query paling mahal.
  2. Perbaiki index, schema, dan pola akses data.
  3. Pisahkan workload yang beda karakter.
  4. Pasang timeout, quota, dan circuit breaker.
  5. Baru naik ke traffic shaping yang lebih advanced kalau skala dan kompleksitasnya memang butuh.

Buat project kecil, lu mungkin belum butuh produk khusus untuk traffic control. Tapi lu tetap butuh cara pikirnya. Karena incident database sering bukan muncul dari satu request jahat. Kadang dia muncul dari fitur baik-baik yang terlalu bebas.

Takeaway buat developer

Pelajaran utamanya sederhana: AI agent butuh guardrail di tempat kerja nyata, bukan cuma di prompt. Kalau agent bisa memanggil tool, tool itu harus punya boundary. Kalau tool bisa menyentuh database, database perlu rem. Kalau workload agent bercampur dengan traffic user, lu perlu prioritas.

Gua suka topik ini karena dia menggeser diskusi AI dari “model mana paling pintar” ke “sistem seperti apa yang tetap aman saat agent mulai bekerja”. Buat developer, skill yang makin penting bukan cuma prompt engineering. Tapi juga resource thinking: timeout, quota, isolation, audit log, dan recovery.

AI agent boleh rajin. Sistem produksi lu tetap harus punya batas.

FAQ singkat

Apakah semua aplikasi perlu database traffic control?

Tidak. Aplikasi kecil bisa mulai dari timeout, indexing yang benar, query limit, role separation, dan observability dasar. Traffic control advanced baru masuk akal saat workload makin beragam dan dampaknya mulai terasa.

Apakah AI agent berbahaya untuk database?

Bukan otomatis berbahaya. Yang berbahaya adalah agent yang diberi tool terlalu bebas tanpa timeout, limit, permission yang sempit, dan audit log.

Apa bedanya rate limit API dan traffic control database?

Rate limit API membatasi jumlah request di layer aplikasi atau edge. Traffic control database lebih dekat ke resource yang mahal: query, koneksi, lock, CPU, memory, dan prioritas workload.

Langkah pertama yang paling praktis apa?

Mulai dari tiga hal: pasang timeout query, batasi tool agent jadi spesifik, dan log semua tool call yang menyentuh data penting.

Referensi / Bacaan Lanjut