Model Biaya DynamoDB: Kenapa SQL Bisa Menyembunyikan Tagihan

Menjalankan SQL sungguhan terhadap DynamoDB itu ampuh — kamu mendapat JOIN, GROUP BY, dan klausa WHERE sembarang di atas sebuah database yang secara native tidak menawarkan satu pun dari itu. Tapi SQL dirancang untuk mesin dengan query planner dan secondary index di setiap kolom, sementara DynamoDB tidak punya keduanya. Sebuah SELECT yang benar-benar sah bisa dikompilasi menjadi Scan seluruh tabel yang membaca — dan menagihmu untuk — setiap item di tabel.

Inilah sisi ganda dari abstraksi SQL: ia membuat pola akses yang mahal tampak gratis. Panduan ini menjelaskan model biaya di baliknya, supaya kenyamanan itu tak pernah berubah menjadi tagihan kejutan, dan menunjukkan bagaimana DynoTable memunculkan biayanya sebelum kamu menjalankan query.

Kenapa SQL di atas DynamoDB berbiaya lebih dari yang terlihat?

Database relasional bisa menjawab WHERE status = 'active' secara efisien karena ia membangun index untuk kolom apa pun yang kamu tanyakan. DynamoDB tidak. Ia menjawab secara efisien tepat pada satu hal: partition key (opsional dipersempit oleh sebuah sort key atau global secondary index). Selain itu adalah Scan.

• Kesamaan partition-key adalah sebuah Query. DynamoDB langsung melompat ke item di bawah key itu dan hanya membaca item-item tersebut. Terbatas dan murah.
• Selain itu adalah Scan + Filter. DynamoDB membaca setiap item di tabel, lalu menerapkan WHERE-mu sebagai sebuah FilterExpression — setelah pembacaan. Kamu ditagih untuk semua yang dipindainya, bukan untuk segelintir baris yang dikembalikan.

Poin terakhir itulah jebakannya. Sebuah klausa WHERE tampak mempersempit pekerjaan. Pada attribute non-key, ia hanya mempersempit keluaran — biaya pembacaan sudah terlanjur dikeluarkan.

Query vs Scan: matematika RCU

DynamoDB menagih pembacaan dalam read capacity unit (RCU):

• 1 RCU = satu pembacaan strongly-consistent atas sebuah item hingga 4 KB. Pembacaan eventually-consistent berbiaya setengah unit. Pembacaan dibulatkan ke atas per 4 KB.
• Sebuah Query hanya membaca item di bawah satu partition key — biayanya berskala dengan item yang cocok, bukan dengan tabel.
• Sebuah Scan membaca seluruh tabel, 4 KB per langkah. Tabel 1 GB kira-kira 262.000 RCU eventually-consistent untuk satu kali lintasan penuh — setiap lintasan, setiap kali.

Sebuah FilterExpression tidak mengurangi angka itu. Pemfilteran terjadi setelah pembacaan, jadi Scan yang terfilter berbiaya persis sama dengan yang tak terfilter. Hitung angka sebenarnya untuk datamu dengan kalkulator ukuran item dan kalkulator harga.

Konstruksi SQL mana yang diam-diam berubah menjadi Scan?

• WHERE tanpa kesamaan partition-key → Scan penuh dengan filter pasca-pembacaan.
• JOIN → tidak ada join sisi-server di DynamoDB. Setiap tabel yang di-join diambil terpisah dan dijahit bersama di sisi klien — sebuah pola akses N+1, satu permintaan per baris yang di-join.
• COUNT, SUM, GROUP BY, agregat → tidak ada agregasi sisi-server, jadi setiap item yang cocok dibaca. Di atas sebuah Scan, itu berarti membaca seluruh tabel.
• ORDER BY atau DISTINCT pada attribute non-key → pengurutan dan de-duplikasi terjadi di sisi klien atas apa pun yang dipindai.

Tak satu pun dari ini salah untuk dijalankan — kadang sebuah Scan memang persis yang kamu mau. Intinya adalah mengetahui kapan kamu menjalankannya.

Bagaimana caraku menjaga SQL jujur soal biaya?

• Rancang key seputar pola aksesmu. Query termurah adalah yang sudah dijawab oleh key schema-mu. Rencanakan dengan alat single-table design dan panduan query vs scan.
• Taruh sebuah kesamaan partition-key di WHERE untuk mendapatkan Query alih-alih Scan.
• Tambahkan sebuah GSI untuk pola akses kedua daripada memindai-dan-memfilter.
• Baca biayanya sebelum kamu menjalankan. Workbench DynoTable mengompilasi SQL-mu menjadi operasi DynamoDB yang sebenarnya dan menampilkan rencananya — Scan vs Query, index mana yang dipakai, key condition vs filter pasca-scan, dan perkiraan biaya RCU — lalu menandai full scan dan N+1 join secara inline. Inilah EXPLAIN yang tak pernah dirilis DynamoDB. Lihat juga kenapa scan lambat dan mahal dan kapasitas on-demand vs provisioned.

Apakah SQL DynoTable memperburuk masalah biaya?

Tidak — karena ia membuat biayanya terlihat. Kritik terhadap SQL-di-atas-DynamoDB itu wajar: abstraksi yang menyembunyikan scan membiarkanmu menembak kaki sendiri. Jawaban DynoTable bukan menghapus SQL-nya, melainkan menempatkan X-ray biaya di baliknya. Setiap query di Workbench mempratinjau bentuk DynamoDB aslinya sebelum berjalan, jadi kamu tetap mendapat ergonomi SQL dan kejujuran soal RCU serta desain key yang diberikan oleh model native-nya.

Apakah aku butuh agen AI untuk semua ini?

Tidak — penampil tabel, SQL Workbench, dan pratinjau biaya semuanya bekerja sepenuhnya tanpa itu. Agen AI adalah salah satu fitur unggulan DynoTable — sebuah coding agent native DynamoDB yang menulis query sadar-schema, mentransformasi data, dan lainnya — dan ia ada kapan pun kamu mau. Ia berjalan di AWS Bedrock milikmu sendiri, jadi kamu membayar AWS langsung sesuai biaya (tanpa markup), dan datamu tak pernah meninggalkan akunmu. Nyalakan saat berguna; klien intinya lengkap dengan atau tanpa itu.

Apakah pekerjaanku portabel?

Ya. DynoTable berbicara dalam standar, bukan taman berdinding: SQL standar, kredensial AWS dan SSO standar, ekspor CSV/JSON, ekspor schema tersimpulkan ke TypeScript, JSON-Schema, atau Zod, dan sebuah server MCP supaya alat dan agenmu sendiri bisa terhubung. Query, konfigurasi, dan schema-mu diekspor dengan bersih — tak ada yang terkunci.

Coba sendiri

Unduh DynoTable dan buka SQL Workbench terhadap tabelmu sendiri — pratinjau biaya menunjukkan berapa sebenarnya biaya setiap query sebelum kamu menjalankannya.