Bagaimana penagihan berlaku untuk Fabric SQL Database yang tidak aktif?

Penagihan komputasi tetap berjalan selama 15 menit setelah kueri terakhir selesai dieksekusi, agar database tetap siap. Setelah itu, biaya komputasi turun menjadi nol. Penyimpanan tetap ditagih setiap jam, terlepas dari aktivitas.

Azure SQL Database vs. Fabric SQL Database: Perbedaan Biaya dan Komputasi

Q: Bagaimana cadangan ditagih di Fabric SQL?

Cadangan pemulihan titik waktu (point-in-time restore) sepenuhnya gratis hingga sebesar total ukuran penyimpanan database aktif Anda. Anda hanya membayar penyimpanan cadangan jika total cadangan melebihi ukuran database utama.

By Mirko Peters · 2026-10-21

Bandingkan biaya komputasi, penskalaan serverless, unit kapasitas, ekonomi penyimpanan, dan trade-off fitur antara Azure SQL Database dan Fabric SQL Database.

Automatically translated with AI from the original post. Read the English original

Cover: Fabric SQL Database - Simply Explained

Memilih antara Azure SQL Database dan Fabric SQL Database bergantung pada pemahaman tentang bagaimana alokasi komputasi, perilaku penskalaan, dan unit kapasitas berbeda. Meskipun keduanya berjalan di atas mesin SQL yang sama-sama andal, integrasi Fabric dengan OneLake dan model kapasitas bersama menghadirkan pertimbangan arsitektur dan biaya yang berbeda bagi organisasi yang berbasis data.

Poin Penting

Fabric SQL Database menggunakan unit kapasitas (CU) Fabric bersama, bukan tingkat vCore Azure yang berdiri sendiri.
Sumber daya komputasi diskalakan ke nol dan dilepaskan secara otomatis setelah 15 menit tidak aktif untuk menghemat biaya.
Penyimpanan ditagih terus-menerus setiap jam, sedangkan penyimpanan cadangan gratis hingga sebesar ukuran database utama Anda.
Mirroring otomatis bawaan menghilangkan pipeline ETL manual dengan mengisi file Delta Parquet di OneLake secara real time.
Azure SQL Database tradisional menyediakan elastic pool khusus dan pekerjaan SQL Server Agent yang ditangani secara berbeda di lingkungan Fabric.

Memahami Komputasi: vCore vs. Unit Kapasitas

Saat memigrasikan beban kerja atau merencanakan arsitektur cloud baru, pergeseran mendasar antara Azure SQL tradisional dan Fabric SQL terletak pada pengelolaan komputasi. Pada Azure SQL Database yang berdiri sendiri, Anda menyediakan vCore khusus atau komputasi Serverless yang terpetakan langsung ke instans database Anda. Anda mengelola batas penskalaan, jendela pemeliharaan, dan tingkat performa per database.

Sebaliknya, Fabric SQL Database mengambil daya komputasinya dari kumpulan kapasitas Fabric yang lebih luas di organisasi Anda. Model sumber daya bersama ini berarti database Anda berbagi anggaran dengan laporan Power BI, pipeline Data Factory, dan Lakehouse. Konversi antara Fabric Capacity Unit (CU) dan daya database ditangani secara dinamis di balik layar. Sebagai contoh, alokasi 64 unit kapasitas kira-kira setara dengan 24,5 vCore untuk beban kerja database Anda. Pendekatan kumpulan terpadu ini mencegah fragmentasi sumber daya yang umum terjadi di lingkungan multi-database, sehingga memungkinkan pembagian sumber daya secara dinamis di seluruh ruang kerja analitik Anda.

Aturan Penskalaan Serverless dan Penagihan Saat Tidak Aktif

Kedua penawaran database ini menggunakan arsitektur serverless yang meningkatkan skala saat eksekusi kueri puncak dan menurunkannya kembali saat lalu lintas berkurang. Namun, mekanisme penagihan untuk waktu tidak aktif sangat penting untuk perkiraan anggaran. Fabric SQL Database memantau aktivitas secara terus-menerus. Jika database benar-benar tidak aktif selama 15 menit tanpa kueri masuk, database tersebut melepaskan semua sumber daya komputasinya sehingga biaya komputasi turun menjadi nol.

Untuk mencegah latensi cold-start bagi pengguna berikutnya, Microsoft menerapkan buffer retensi yang disengaja. Jika database bekerja keras selama dua menit lalu menjadi senyap, Anda ditagih untuk dua menit aktif tersebut ditambah 15 menit tambahan komputasi siaga (warm-standing), sehingga totalnya 17 menit. Namun, penyimpanan tetap dan ditagih setiap jam, baik database sedang memproses transaksi maupun tidak.

Biaya Penyimpanan dan Ekonomi Cadangan

Pengelolaan penyimpanan di Fabric SQL Database menghadirkan keunggulan penghematan biaya yang signifikan dibandingkan dengan pengaturan lama. Karena database secara otomatis memulai mirroring berkelanjutan ke OneLake, catatan operasional Anda diduplikasi ke dalam berkas Delta Parquet yang terbuka. Format terbuka ini memastikan data Anda tidak pernah terkunci dalam silo milik vendor tertentu, sehingga alat apa pun yang mampu membaca format Delta dapat langsung melakukan kueri pada salinan yang dicerminkan.

Selain itu, ekonomi cadangan juga sangat dioptimalkan di ekosistem Fabric. Kemampuan pemulihan point-in-time memungkinkan administrator memutar waktu hingga tujuh hari ke belakang untuk memulihkan data dari kerusakan yang tidak disengaja atau kesalahan pengguna yang berakibat fatal. Penyimpanan cadangan sepenuhnya gratis hingga sebesar total ukuran database utama Anda. Biaya tambahan hanya timbul jika ukuran penyimpanan cadangan melampaui ukuran database aktif itu sendiri, sehingga memberikan jaring pengaman finansial yang dapat diprediksi untuk retensi data jangka panjang.

Trade-off Operasional: Apa yang Anda Dapatkan dan Apa yang Hilang

Meskipun mesin SQL inti identik di kedua platform, memilih Fabric SQL Database dibandingkan Azure SQL Database mengharuskan Anda mengevaluasi trade-off fitur tertentu. Mengetahui apa yang tidak ada di implementasi Fabric mencegah hambatan arsitektur yang tidak terduga selama pengembangan.

Fitur Khusus Azure SQL Tradisional

Azure SQL Database mandiri mendukung elastic pool secara native berdasarkan nama, memberi administrator database kontrol granular atas pengelompokan database. Platform ini juga menyertakan SQL Server Agent klasik, yang banyak diandalkan aplikasi lama untuk menjadwalkan stored procedure dan tugas pemeliharaan secara internal.

Keunggulan Native Fabric SQL

Fabric SQL menghilangkan beban administratif dalam menyiapkan pipeline replikasi eksternal. Begitu Anda membuat database, mirroring langsung aktif untuk semua tabel yang didukung tanpa memerlukan konfigurasi ETL manual. Selain itu, layanan ini terintegrasi secara native dengan Git untuk kontrol sumber dan mendukung konvensi penamaan tiga bagian, sehingga Anda dapat dengan mudah menggabungkan tabel operasional dengan Lakehouse dan Warehouse dalam satu kueri. Untuk gambaran lengkap tentang bagaimana semua komponen ini saling terhubung, Dengarkan episode lengkapnya untuk mendapatkan analisis dari para ahli serta strategi praktis bagi arsitek data modern.

Pertanyaan Umum

Bagaimana penagihan untuk Fabric SQL Database yang tidak aktif?

Penagihan komputasi berlanjut selama 15 menit setelah kueri terakhir selesai dijalankan untuk menjaga database tetap siaga, setelah itu biaya komputasi turun menjadi nol. Penyimpanan tetap ditagih per jam tanpa memandang aktivitas.

Apakah saya perlu mengonfigurasi mirroring secara manual agar data masuk ke OneLake?

Tidak. Mirroring dimulai secara otomatis begitu Fabric SQL Database dibuat, dan terus menyinkronkan tabel relasional Anda ke OneLake sebagai berkas Delta Parquet terbuka tanpa memerlukan kode ETL kustom.

Bisakah saya menggunakan SQL Server Agent untuk menjadwalkan tugas di Fabric SQL Database?

SQL Server Agent tidak tersedia di Fabric SQL Database. Sebagai gantinya, Microsoft merekomendasikan penggunaan pipeline Data Factory atau tugas Apache Airflow untuk penjadwalan dan otomatisasi.

Bagaimana cadangan ditagih di Fabric SQL?

Cadangan point-in-time restore sepenuhnya gratis hingga sebesar total ukuran penyimpanan database aktif Anda. Anda hanya membayar penyimpanan cadangan jika jejak cadangan melampaui ukuran database utama.