Haber

Netlify Storage Nedir? Database ve Blobs Arasındaki Farklar

Netlify Storage, Netlify üzerinde çalışan uygulamaların verisini platform dışındaki ayrı altyapıyı elle kurmadan saklamak için sunulan veri primitive’lerini ifade eder. 2026’daki iki temel seçenek Netlify Database ve Netlify Blobs’tur.

Netlify Storage Nedir? Database ve Blobs Arasındaki Farklar
Bu yazıda 17 başlık
  1. Öne Çıkanlar
  2. Netlify Storage Ekosistemi Nedir?
  3. Netlify Database Nedir?
  4. Netlify Blobs Nedir?
  5. Yapılandırılmış ve Yapılandırılmamış Veri Farkı
  6. Database ve Blobs Karşılaştırma Tablosu
  7. Preview Deploy ile Veri İzolasyonu Nasıl Çalışır?
  8. Tutarlılık ve Concurrency Farkı
  9. Güvenlik, Erişim ve PII
  10. Maliyet ve Limitler Nasıl Araştırılmalı?
  11. Karar Ağacı
  12. Gerçek Kullanım Senaryoları
  13. Zorunlu Aynı-Kayıt Testi
  14. Netlify Storage Kontrol Listesi
  15. Sık Sorulan Sorular
  16. Kaynaklar
  17. Sonuç

Netlify Storage, Netlify üzerinde çalışan uygulamaların verisini platform dışındaki ayrı altyapıyı elle kurmadan saklamak için sunulan veri primitive’lerini ifade eder. 2026’daki iki temel seçenek Netlify Database ve Netlify Blobs’tur. Database; ilişkiler, filtreleme, transaction ve SQL gerektiren yapılandırılmış veri için yönetilen serverless Postgres sunar. Blobs ise dosya, JSON çıktısı ve basit key-value kayıtları gibi yapılandırılmamış veya anahtar üzerinden erişilen veriler için daha yalın bir store modelidir.

İki ürün birbirinin “küçük” ve “büyük” sürümü değildir. Kararı veri boyutundan önce erişim modeline göre vermek gerekir: “Hangi key’deki object’i getir? ” sorusu baskınsa Blobs; “Kullanıcılar, siparişler ve ürünler arasında ilişki kur, filtrele ve transaction yap” ihtiyacı varsa Database daha doğal başlangıçtır.

Netlify Storage Nedir? Database ve Blobs Arasındaki Farklar

Öne Çıkanlar

  • Netlify Database, SQL ve ilişkisel schema kullanan yönetilen Postgres’tir.
  • Netlify Blobs, sık okuma ve seyrek yazma için optimize edilmiş object/key-value store’dur.
  • Database; user profile, inventory ve transaction log gibi yapılandırılmış veriler için uygundur.
  • Blobs; file upload, JSON output, sitemap ve media işleme sonucu gibi unstructured veriler için uygundur.
  • Database Deploy Preview’lar için izole database branch oluşturabilir.
  • Site-wide Blobs store’ları deploy context’leri arasında paylaşılabilir; bu nedenle preview’ın production verisine erişme riski ayrıca yönetilmelidir.
  • Database’in compute ve bandwidth’i kredi tüketir; storage fiyat dokümanında geçmiş bir tarih bulunması nedeniyle güncel depolama oranı satın alma gününde ayrıca doğrulanmalıdır.
Netlify Storage Nedir? Database ve Blobs Arasındaki Farklar

Netlify Storage Ekosistemi Nedir?

Netlify’nin data ve storage katmanı, frontend ile serverless/edge compute arasında yönetilen veri servisleri sunar. Uygulama kodu Functions, Edge Functions, framework server routes, build adımları veya desteklenen agent workflow’larından veriye erişebilir.

Basit mimari:

``text UI / framework route ↓ Function veya Edge Function ↓ Netlify Database ya da Netlify Blobs ↓ Deploy Preview / Production context ``

Platformun iki storage ürünü farklı veri sorularını çözer:

SoruDoğal tercih
Bu kullanıcıya ait son 20 siparişi tarihe göre filtreleDatabase
report/2026-08.json object’ini getirBlobs
Ürün stok güncellemesini transaction içinde yapDatabase
Formdan gelen image dosyasını key ile saklaBlobs
Tag ve kategori ilişkileri üzerinden arama yapDatabase
Background Function çıktısını daha sonra okuBlobs

Bir uygulamada ikisi birlikte de kullanılabilir. Örneğin ürün metadata’sı ve stok Database’de; büyük image veya generated report dosyaları Blobs’ta saklanabilir. Database kaydı Blobs key’ine referans verir.

Netlify Database Nedir?

Netlify Database, Netlify platformuna entegre tam yönetilen Postgres hizmetidir. Provisioning, migration lifecycle, database branching, backup ve erişim guardrail’leri platform tarafından yönetilir; schema, query ve uygulama mantığı ekip tarafından tasarlanır.

Öne çıkan yetenekler:

  • SQL ve ilişkisel schema,
  • Primary/foreign key,
  • Index ve constraint,
  • Transaction,
  • Join, aggregate ve complex query,
  • Drizzle ORM veya direct SQL,
  • Local Postgres development,
  • Deploy Preview database branches,
  • Otomatik migration uygulama,
  • Dashboard üzerinden branch ve kullanım görünümü,
  • Auto-scale ve inactivity sonrası sleep.

Netlify CLI ile mevcut projeye eklenebilir:

``bash netlify database init ``

Komut @netlify/database paketini ve seçilen akışa göre diğer bağımlılıkları kurabilir, Drizzle veya direct SQL seçimi sunabilir ve başlangıç migration’ı oluşturabilir. Yerel geliştirmede netlify dev tam Postgres ortamı başlatır.

Örnek relational model:

```sql CREATE TABLE users ( id BIGSERIAL PRIMARY KEY, email TEXT NOT NULL UNIQUE, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() );

CREATE TABLE orders ( id BIGSERIAL PRIMARY KEY, user_id BIGINT NOT NULL REFERENCES users(id), total_cents INTEGER NOT NULL CHECK (total_cents >= 0), status TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); ```

Bu modelde belirli kullanıcının siparişlerini filtrelemek, toplam harcamayı hesaplamak ve status bazlı rapor üretmek SQL ile doğal biçimde yapılır.

Netlify Blobs Nedir?

Netlify Blobs, blob ve yapılandırılmamış veriyi saklayan; aynı zamanda basit key-value store olarak kullanılabilen yüksek erişilebilir bir data store’dur. Sık okuma ve seyrek yazma profiline optimize edilir.

Başlangıç:

``bash npm install @netlify/blobs ``

Basit kullanım:

```ts import { getStore } from "@netlify/blobs";

const store = getStore("reports");

await store. setJSON("daily/2026-08-23", { total: 42, generatedAt: new Date(). toISOString() });

const report = await store. get("daily/2026-08-23", { type: "json" }); ```

Blobs için temel kavramlar:

  • Store: Namespace benzeri veri alanı.
  • Key: Object’i bulan benzersiz string.
  • Value: String, JSON, ArrayBuffer, stream veya file benzeri content.
  • Metadata: Object hakkında küçük ek veri.
  • List: Prefix üzerinden key listeleme.
  • Consistency mode: Eventual varsayılan; gerektiğinde strong read.
  • Store scope: Site-wide veya deploy-specific.

Blobs, SQL query engine değildir. status = 'pending' AND created_at > ... gibi sorgular için bütün object’leri listeleyip uygulama kodunda filtrelemek hem verimsiz hem hata eğilimlidir. Bu ihtiyaç büyüyorsa Database kullanılmalıdır.

Yapılandırılmış ve Yapılandırılmamış Veri Farkı

“JSON yapılandırılmıştır, o hâlde Database gerekir” veya “Dosya büyüktür, o hâlde Blobs gerekir” gibi basit eşlemeler yeterli değildir. Asıl fark schema ve query modelidir.

Database için güçlü işaretler

  • Birden fazla entity arasında ilişki var.
  • Unique, foreign key veya check constraint gerekiyor.
  • Transaction içinde birden fazla kayıt değişecek.
  • Filtre, sort, aggregate ve pagination gerekiyor.
  • Aynı alanlar sık güncelleniyor.
  • Ad hoc query ve raporlama gerekiyor.
  • Concurrency conflict kontrollü yönetilmeli.

Blobs için güçlü işaretler

  • Veriye key üzerinden erişiliyor.
  • Object genellikle bütünüyle yazılıp bütünüyle okunuyor.
  • Dosya veya büyük metin/JSON output’u saklanıyor.
  • Schema zorunlu değil veya uygulama tarafından versionlanıyor.
  • Sık okuma, daha seyrek update/write var.
  • Background processing sonucu persist edilecek.
  • SQL relationship ve transaction gerekmiyor.

Aynı JSON kaydı iki yerde de saklanabilir; bu, iki ürünün eşdeğer olduğu anlamına gelmez. JSON içindeki her property’ye filtreli query gerekiyorsa Postgres JSONB veya normal kolonlar daha uygundur. JSON yalnız tek key ile alınıp gösterilecekse Blobs daha sade olabilir.

Database ve Blobs Karşılaştırma Tablosu

KriterNetlify DatabaseNetlify Blobs
Veri modeliİlişkisel, structuredObject/key-value, unstructured
SorgulamaSQL, join, filter, aggregateKey get/set, list/prefix
SchemaMigration ile açıkUygulama tarafından isteğe bağlı
TransactionPostgres transactionGenel multi-object transaction yok
ConcurrencyConstraint/transaction/lock mekanizmalarıLast-write-wins; built-in conflict control yok
GüncellemeKolon/row düzeyindeGenellikle object’i yeniden yazma
DosyaUygun değil veya bytea dikkatliDoğal kullanım alanı
Preview isolationDynamic database branchStore türü ve key tasarımıyla yönetilir
Local devYerel PostgresLocal sandbox store
Query complexityYüksekDüşük
Tipik örnekUser, order, inventoryUpload, report, sitemap, generated media

Preview Deploy ile Veri İzolasyonu Nasıl Çalışır?

Database branching

Netlify Database’in ayırt edici özelliklerinden biri Deploy Preview ile database branch entegrasyonudur. Pull request deploy’unda migration, production’dan izole preview database branch’ine uygulanabilir. Ekip schema ve veri değişikliğini canlı database’i etkilemeden test eder.

Production migration publish öncesinde uygulanır ve hata verirse deploy’un yayınlanmasını engeller. Preview migration başarısız olursa preview deploy da başarısız olur. Bu entegrasyon schema ile kod sürümünü birlikte review etmeyi kolaylaştırır.

Database branch izolasyonu sınırsız güvenlik garantisi değildir. Preview Function yanlış connection string veya harici production servisi kullanıyorsa canlı veriye yine erişebilir. Environment scope ve access role ayrıca doğrulanmalıdır.

Blobs store kapsamı

Site-wide Blobs store, site içindeki deploy context’leri tarafından paylaşılabilir. Bu, production ve Deploy Preview’ın aynı store’u görmesine yol açabilir. Preview’da test write’ı gerçek production object’ini overwrite edebilir.

Daha güvenli seçenekler:

  • Deploy-specific store kullanmak,
  • Key’e context/deploy ID prefix’i eklemek,
  • Preview için ayrı store adı kullanmak,
  • Production write yetkisini preview’dan kaldırmak,
  • Sadece sentetik test object’leri kullanmak.

Deploy-specific store için API getDeployStore yaklaşımı sunar. Bu store deploy lifecycle’ına bağlı content için uygundur; site-wide kalıcı iş verisiyle aynı amaçta değildir.

Tutarlılık ve Concurrency Farkı

Database, transaction ve constraint’lerle eş zamanlı değişiklikleri yönetmek için tasarlanır. Örneğin stok 1 iken iki kullanıcının aynı ürünü satın almasını transaction ve row-level logic ile kontrol edebilirsiniz.

Blobs varsayılan eventual consistency kullanır. Yeni object global olarak hemen erişilebilir hâle gelebilir; update ve delete’in tüm bölgelere yayılması belirli süre alabilir. Netlify dokümanı update/delete için 60 saniye içinde garanti veren eventual model tanımlar. Strong consistency read seçeneği daha güncel okumayı sağlar; latency trade-off’u olabilir.

Blobs last-write-wins modeline sahiptir ve built-in concurrency control sağlamaz. Aynı key’e iki yazma yarışıyorsa son yazan kazanır; optimistic version check veya ayrı coordination katmanı uygulama tarafından eklenmelidir.

Bu nedenle balance, inventory veya idempotency record gibi doğruluk kritik veriyi basit Blobs key’i olarak tasarlamak risklidir. Database transaction daha doğru olabilir.

Güvenlik, Erişim ve PII

İki storage ürünü de server-side erişim modeliyle kullanılmalıdır. Browser’ın doğrudan production database connection string veya unrestricted Blobs credential görmemesi gerekir.

Database

  • Connection string’i server-side scope’ta tutun.
  • Team role ve database dashboard permission’larını minimum yetkiyle ayarlayın.
  • Production data görüntüleme ve düzenleme yetkisini ayırın.
  • SQL injection’a karşı parameterized query kullanın.
  • Migration’da destructive değişiklikleri iki aşamalı yapın.
  • Backup/recovery politikasını gerçek iş gereksinimiyle doğrulayın.
  • Payment card ve HIPAA gibi compliance sınırlarını resmî dokümandan kontrol edin.

Blobs

  • Store adını güvenlik sınırı olarak kabul etmeyin.
  • Key tahmin edilemez olsa bile authorization kontrolü yapın.
  • User-controlled file için size, content type, malware ve access kontrolü uygulayın.
  • PII object’leri list endpoint’inde istemeden açmayın.
  • Metadata içine secret veya hassas veri koymayın.
  • Preview’ın site-wide store’a erişimini sınırlandırın.
  • Netlify dokümanında Blobs için HIPAA hosting desteğinin bulunmadığını yayın tarihinde doğrulayın.

Encryption ve platform güvenliği önemli bir temel sağlar; yanlış authorization veya public Function endpoint’i yine veri sızıntısı yaratabilir.

Maliyet ve Limitler Nasıl Araştırılmalı?

Netlify Database kredi tabanlı planlarda kullanılabilir. Aktif database compute ve outbound bandwidth kredi tüketir. 23 Ağustos 2026 tarihli resmî billing dokümanında:

  • Database compute için güncel kredi ölçümü,
  • Database bandwidth için GB bazlı kredi,
  • Plan bazlı limitler,
  • Auto-scale ve sleep davranışı

açıklanır.

Ancak aynı dokümanda database storage için “1 Temmuz 2026’ya kadar ücretsiz” ve “en erken 1 Temmuz 2026’da ücretlendirilecek” ifadeleri hâlâ yer alıyor. Bu tarih geçmişte kaldığı için, metin güncel storage fiyatını açıklamıyor. Yayın veya satın alma öncesinde dashboard, güncel pricing dokümanı ve gerekirse Netlify Support üzerinden storage rate teyit edilmelidir. Eski geçici ücretsiz dönem güncel fiyat gibi aktarılmamalıdır.

Blobs için object boyutu, key/store adı, metadata ve usage limitleri resmî dokümanda kontrol edilmelidir. Güncel doküman; object başına 5 GB, metadata için 2 KB ve key/store adlarına belirli byte sınırları belirtir. Plan, kredi ve legacy hesap davranışı ayrıca değişebilir.

Maliyet hesabında yalnız saklanan GB’a bakmayın:

  • Database ne kadar süre aktif?
  • Sleep timeout nedir?
  • Auto-scale minimum/maksimum compute ne?
  • Query ne kadar data döndürüyor?
  • Blobs object’leri ne sıklıkta okunuyor/yazılıyor?
  • Aynı veriyi preview ve production duplicate ediyor musunuz?
  • Function/Edge compute ve bandwidth de tüketiliyor mu?

Karar Ağacı

Aşağıdaki soruları sırayla yanıtlayın:

  1. SQL query, join veya aggregate gerekiyor mu? - Evet → Database. 2. Birden fazla kaydı atomik transaction içinde değiştirmek gerekiyor mu? - Evet → Database. 3. Veri esasen file veya tek key üzerinden okunan object mi? - Evet → Blobs. 4. Aynı object sık sık eş zamanlı güncelleniyor mu? - Evet → Database veya ek concurrency katmanı. 5. Preview değişiklikleri production verisinden izole edilmeli mi? - İki üründe de mümkün; Database branch daha native, Blobs’ta store/key scope tasarlanmalı. 6. Ad hoc rapor veya filtre ihtiyacı büyüyecek mi? - Evet → Database. 7. Background job yalnız çıktı dosyası üretiyor mu? - Evet → Blobs. 8. İki veri biçimi de var mı? - Metadata Database + binary/output Blobs hibriti.

Gerçek Kullanım Senaryoları

E-ticaret katalogu

  • Product, category, stock, order: Database.
  • Product image ve generated export: Blobs.
  • Database row Blobs key’ini saklar.

Form ve AI özetleme

  • Submission metadata, status, reviewer: Database.
  • Raw large attachment ve generated summary artifact: Blobs.
  • PII minimizasyonu ve retention ayrı uygulanır.

Dokümantasyon sitesi

  • Build sırasında generated search index: deploy-specific Blobs veya static asset.
  • User profile/favorite docs: Database.

Media processing

  • Job status ve ownership: Database.
  • Original/processed file: Blobs.
  • Background Function sonucu object key ile kaydedilir.

Basit feature flag

  • Küçük, seyrek değişen config: Blobs.
  • Çok boyutlu segment query, audit ve transaction: Database veya özel feature flag servisi.

Zorunlu Aynı-Kayıt Testi

Aynı sentetik kayıt iki üründe saklanmalıdır:

``json { "id": "demo-001", "category": "documentation", "status": "draft", "score": 4, "createdAt": "2026-08-23T12:00:00Z" } ``

Test matrisi:

İşlemDatabaseBlobsKaydedilecek
CreateINSERTsetJSONSüre, status, hata
Read by IDPrimary key querygetSonuç doğruluğu
Filter by statusSQL WHEREListe + app filterKod/işlem farkı
Update scoreUPDATE columnObject rewriteConcurrency/tutarlılık
DeleteDELETEdeleteGörünürlük süresi
Preview isolationDB branchDeploy/site storeProduction etkisi
Schema changeMigrationApp-level versionRollback yaklaşımı

Mikro benchmark aynı network, runtime, payload ve örneklemle yapılmalıdır. Tek object üzerinde birkaç milisaniyelik fark, ürünlerin genel performansını temsil etmez; asıl amaç developer experience ve veri modelini karşılaştırmaktır.

> Editör notu — zorunlu özgün kanıt: Bu taslak hazırlanırken aynı JSON kaydı gerçek Netlify Database ve Blobs ortamlarına yazılmadı. Yayından önce yalnız sentetik veriyle create/read/filter/update/delete ve Deploy Preview izolasyon testleri yapılmalı; Netlify CLI, Node ve package sürümleri, commit SHA, region, consistency mode, query/store kodu ve ham sonuçlar kaydedilmelidir. Tek mikro benchmark evrensel performans sonucu olarak sunulmamalıdır.

> Görsel notu: Structured SQL graph ile key-value object modelini, ayrıca Preview → database branch ve Preview → site/deploy Blobs store farkını gösteren iki özgün şema hazırlanmalıdır.

> İç link editör notu: Netlify Database, Blobs, Functions ve AI form özetleme yazıları yayımlandığında ilgili kullanım senaryolarına doğal bağlantı eklenmelidir.

Netlify Storage Kontrol Listesi

  • [ ] Erişim modeli key lookup mı, SQL query mi belirlendi.
  • [ ] Transaction ve concurrency ihtiyacı yazıldı.
  • [ ] Structured/unstructured veri ayrımı yapıldı.
  • [ ] Preview ile production izolasyonu test edildi.
  • [ ] Database migration ve rollback planı var.
  • [ ] Blobs site-wide/deploy-specific store seçimi bilinçli.
  • [ ] PII ve file güvenlik kontrolleri tanımlandı.
  • [ ] Browser’a unrestricted credential açılmıyor.
  • [ ] Compute, bandwidth ve storage fiyatı güncel kaynaktan teyit edildi.
  • [ ] Aynı sentetik kayıt iki üründe gerçek test edildi.

Sık Sorulan Sorular

Netlify Storage tek bir ürün mü?

Hayır. Netlify’nin data/storage ekosisteminde başlıca Database ve Blobs bulunur; farklı veri modellerine hizmet ederler.

JSON veri için Database mi Blobs mı?

JSON key üzerinden bütünüyle alınıyorsa Blobs yeterli olabilir. Property’lere göre filtre, ilişki, transaction ve ad hoc query gerekiyorsa Database daha uygundur.

Dosyayı Postgres içinde saklamak doğru mu?

Küçük binary teknik olarak mümkün olsa da büyük file için object storage daha doğal ve maliyet/operasyon açısından daha yönetilebilir olabilir. Database’de metadata ve Blobs key’i tutulabilir.

Deploy Preview verisi otomatik izole olur mu?

Database, preview branch entegrasyonu sunar. Blobs’ta site-wide store tüm context’lerce görülebileceği için deploy-specific store, ayrı store adı veya context prefix’i tasarlanmalıdır.

Netlify Database storage ücretsiz mi?

Resmî dokümandaki geçici ücretsiz tarih 1 Temmuz 2026’da sona ermiş görünüyor; 23 Ağustos 2026 itibarıyla aynı sayfa güncel storage oranını açıkça belirtmiyor. Satın alma gününde dashboard ve Netlify desteği üzerinden doğrulama gerekir.

Kaynaklar

Sonuç

Netlify Storage seçiminde temel soru verinin kaç megabayt olduğu değil, nasıl okunup değiştirildiğidir. İlişkisel schema, SQL, transaction, filtre ve güçlü concurrency gereken iş verisi için Netlify Database; key üzerinden alınan file, JSON output ve basit object verisi için Netlify Blobs daha doğru başlangıçtır. Birçok production uygulamada iki ürünü hibrit kullanmak doğaldır. Preview izolasyonunu ve yetkilendirmeyi ürün adına güvenerek değil, gerçek deploy testiyle doğrulayın; özellikle Database storage fiyatındaki geçmiş tarihli doküman ifadesini satın alma gününde yeniden teyit edin.

Database ve Blobs seçeneklerini kendi veri modelinizle denemek için [ücretsiz hesap oluşturabilirsiniz](https://join. netlify. com/wmkqymu1heo2). Bu bir iş ortaklığı bağlantısıdır; bağlantı üzerinden kayıt olmanız veya ücretli plana geçmeniz halinde Ortak Alan komisyon kazanabilir.

Yazar

Keşfet
  1. HaberLes Misérables Hudson Valley’de: Barikatlar Nehri AşıyorBora Gökçe ·
  2. KültürAI İçin Sanat Eserlerini Kazıyan Kişi, Artık Yaratıcılarla İşbirliği YapıyorBora Gökçe ·
  3. HaberBLS Verilerindeki Küçük Düzeltme Daha Güvenilir İstihdam Rakamlarını GösteriyorBora Gökçe ·

Ücretsiz üyelik

Ortak Alan’a katıl.

Kısa bir kayıt. Ardından Ghost sana e-posta doğrulama bağlantısı gönderecek.

Tamamdır. Devam etmek için e-postandaki bağlantıyı kontrol et.

Zaten üye misin?Giriş yap