Paket seçimi performans kadar maliyet sözleşmesidir
Müşteri bir database paketi seçtiğinde yalnızca bugünkü CPU/RAM ihtiyacını değil, büyüme ve operasyon modelini de seçer. Canlı depolama nasıl artacak, yedek ne kadar saklanacak, PITR açık mı olacak, geri yükleme hedefi ücretli mi? Bunlar paket dilinde açık değilse fatura sürpriz olur.
Sağlıklı paketleme iki dili birleştirir: müşterinin anlayacağı ürün dili ve altyapının ölçebileceği ölçümleme dili. İkisi koparsa satış başka, operasyon başka gerçeklik yaşar.
- Compute aktif node süresiyle ölçülür.
- Canlı depolama kullanılan byte değil, çoğu zaman provisioned volume üzerinden okunur.
- Yedek depolama canlı depolamadan ayrı büyüyebilir.
- PITR arşivi retention uzadıkça maliyet üretir.
- Geri yükleme hedefleri geçici olsa bile ölçülmeli ve serbest pencere açık tanımlanmalıdır.
Yedek maliyetini canlı veriyle karıştırmayın
Bir cluster 200 GB canlı veriye sahip olabilir ama yedek ve PITR arşivi bunun birkaç katına çıkabilir. Özellikle sık değişen OLTP sistemlerde WAL/binlog/oplog arşivleri retention süresine bağlı olarak büyür.
Bu nedenle “depolama paketim yetiyor” demek yedek maliyeti için yeterli cevap değildir. Yedek saklama süresi, PITR penceresi ve arşiv politikası ayrıca gözden geçirilmelidir.
Maliyet kalemlerini ayrı okuma
compute -> aktif node-hour live_storage -> provisioned GB-hour yedek_storage -> tamamlanmış yedek objeleri pitr_archive -> değişiklik arşivleri restore_target -> geçici cluster işlem kaynağı/depolama credit -> outage, destek veya kampanya düzeltmesi
Geri yükleme hedefini ücretsiz pencereyle yönetin
Geri yükleme testi için açılan hedef clusterlar çok değerlidir; ama unutulursa maliyet üretir. İyi modelde geri yükleme hedefi belirli süre ücretsiz değerlendirme penceresine sahip olur, sonra ya silinir ya da müşteri tarafından tutulup ücretli hale gelir.
Bu davranış sadece fatura için değil, müşteri güveni için de önemlidir. “Geri yükleme ettik, kontrol edin” denildiğinde müşteri ne kadar süresi olduğunu ve sonra ne olacağını bilmelidir.
Geri yükleme hedefi maliyet kontrolü
turkdb cluster pitr restore app-pg \ --time "2026-06-14T09:00:00Z" \ --name app-pg-restore-check turkdb billing usage --cluster app-pg-restore-check turkdb cluster delete app-pg-restore-check --confirm
Müşteri faturası ve iç maliyet aynı kayıt akışından beslenmeli
Başarısız provisioning müşteriye fatura edilmemelidir; ama sağlayıcı açısından iç maliyet olarak görünmelidir. Aynı şekilde destek nedeniyle uzatılan retention müşteriye yansıtılmayabilir ama platform maliyetinde durmalıdır.
TürkDB ölçümleme politikasındaki ayrım burada kritik hale gelir: müşteriye faturalanabilir ve iç maliyet aynı ham kayıt üzerinde farklı boyutlar olarak taşınır. Böylece müşteri faturası adil, şirket maliyet raporu gerçekçi olur.