Kapan sebaiknya Anda tidak memakai DynamoDB?

Lewati DynamoDB ketika beban kerja Anda bersifat analitik atau pola akses Anda belum diketahui. DynamoDB dibangun khusus untuk beban kerja operasional (OLTP) dengan pola akses berbasis key yang sudah diketahui — ia tidak punya join maupun fungsi agregat, dan query ad-hoc jatuh kembali ke scan seluruh tabel yang mahal. Untuk pelaporan OLAP atau kebutuhan relasional yang terus berkembang, pilih mesin lain.

Kecocokan yang buruk

Analitik dan pelaporan ad-hoc (OLAP) — tidak ada GROUP BY, SUM, atau AVG; setiap rollup adalah sebuah scan atau agregat pra-hitung yang Anda pelihara sendiri. Lihat panduan agregasi untuk solusi akalnya.
Schema relasional ternormalisasi — DynamoDB sengaja meniadakan operator JOIN; panduan AWS sendiri menyuruh mendenormalisasi.
Pola akses yang belum diketahui atau cepat berubah — Anda merancang key-nya di sekitar query-nya. Ketika Anda belum bisa menyebutkan query-nya, setiap query baru berisiko berarti perancangan ulang tabel atau sebuah scan penuh.
Pencarian teks lengkap dan query yang kaya — lihat apakah DynamoDB mendukung pencarian teks lengkap?; pencarian tempatnya di index pencarian.
Objek besar — item dibatasi 400 KB; media dan dokumen tempatnya di S3 dengan pointer di tabel.

Rollup yang ditolak, lalu dihitung harganya

Ketidakcocokan analitiknya bukan soal selera. Minta DynamoDB melakukan penghitungan berkelompok di PartiQL dan pernyataannya ditolak sebelum ia membaca apa pun:

SELECT status, COUNT(*) FROM "orders" GROUP BY status

ValidationException: Unsupported clause: GROUP BY
HTTP 400

Buang pengelompokannya lalu minta total polosnya, dan ia gagal satu langkah lebih awal, di parser:

SELECT COUNT(*) FROM "orders"

ValidationException: Unexpected path component at 1:8:5
HTTP 400

COUNT sama sekali bukan fungsi dalam dialek ini, jadi parser-nya membacanya sebagai path atribut lalu menyerah di kurungnya.

Yang tersisa adalah Scan yang Anda tulis sendiri, dan itu ada harganya. Membaca tabel 50 GB dari ujung ke ujung menghabiskan 6.553.600 read unit eventually consistent, yaitu ukuran agregat hasil scan dalam satuan 4 KB, dibagi dua. Di us-east-1 on-demand itu $0.82.

Refresh satu angka itu tiap jam dan jadinya $598 sebulan. Memelihara counter-nya sambil menulis, atau mengekspor ke penyimpanan analitik, adalah jawaban yang lebih murah, dan keduanya adalah pekerjaan yang tidak dilakukan DynamoDB untuk Anda.

Di mana ia bersinar

Daftar kebalikannya persis adalah titik manis DynamoDB: beban kerja operasional bervolume tinggi dengan baca dan tulis berbasis key yang bisa diprediksi dan harus tetap satu digit milidetik pada skala berapa pun — keranjang belanja, sesi, profil, state game, event IoT. Panduan kapan memakai DynamoDB menyusun argumen positifnya.

Pelajari lebih lanjut

Kalau Anda masih ragu, baca kapan memakai DynamoDB berikutnya. Sudah di DynamoDB dan merindukan SQL? DynoTable menjalankan JOIN dan GROUP BY terhadap tabel live dari desktop — dan kalkulator harga memberi tahu berapa biaya beban kerja Anda sebelum Anda memutuskan.

Referensi

Terakhir diverifikasi 2026-07-13 terhadap dokumentasi resmi AWS yang ditautkan di atas. Angka 400 KB dikonfirmasi ulang 2026-07-28; AWS telah memindahkannya dari halaman service quotas ke Constraints.html.

Direproduksi 2026-07-28 terhadap DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 pada Node v24.18.0; kedua pesan ValidationException dikutip apa adanya. Biaya Scan-nya dihitung dari tarif us-east-1 dalam tabel harga AWS yang kami sinkronkan.