Netlify Blobs

Netlify Blobs, dosya, JSON, metin ve basit key-value verilerini Netlify projesine bağlı store’larda saklamanızı sağlayan object storage hizmetidir. Veriye SQL sorgusuyla değil, store adı ve benzersiz key üzerinden erişilir. Sık okunan fakat daha seyrek yazılan content, generated report, file upload, cached API sonucu veya build artifact’i gibi kullanım senaryolarına uygundur.

Netlify Blobs bir ilişkisel database değildir. Join, transaction, row-level query veya built-in concurrency control gerektiren veriler için Netlify Database daha doğal seçimdir. Blobs’ta aynı key’e çakışan iki write olduğunda last-write-wins davranışı geçerlidir; yarış koşulunu uygulama yönetmelidir.

Öne Çıkanlar

• @netlify/blobs paketi Functions, Edge Functions, Build Plugins ve diğer desteklenen ortamlardan kullanılabilir.
• Site-wide store deploy’lar arasında kalıcıdır ve farklı deploy context’lerinden erişilebilir.
• Deploy-specific store belirli deploy’a bağlıdır; rollback ve otomatik deploy deletion lifecycle’ıyla birlikte hareket eder.
• set, setJSON, get, getWithMetadata, list, delete ve deleteAll gibi API’ler bulunur.
• Varsayılan model eventual consistency’dir; yeni object global olarak hemen erişilebilir, update/delete değişiklikleri edge noktalarına 60 saniye içinde yayılır.
• Strong consistency store veya read operation seviyesinde seçilebilir ve daha yavaş read trade-off’u getirir.
• Object başına güncel üst sınır 5 GB, metadata üst sınırı 2 KB, key üst sınırı 600 byte’tır.
• Blobs, 23 Ağustos 2026 itibarıyla Netlify’nin HIPAA-compliant hosting teklifinin parçası değildir.

Netlify Blobs Nedir ve Hangi Veri Modelini Kullanır?

Netlify Blobs, her kaydı şu iki ana öğeyle saklar:

``text store + key → value (+ optional metadata) ``

Örnek:

``text Store: reports Key: monthly/2026-08.json Value: { ...JSON content... } Metadata: { generatedBy: "summary-job", version: 3 } ``

Bir store, namespace gibi davranır. Aynı key farklı store’larda farklı object’leri gösterebilir. Key path benzeri / karakterleri içerebilir; ancak key / ile başlayamaz. Store adında / ve : kullanılamaz.

Blobs güçlü bir adaydır:

• Kullanıcı upload’ları,
• Generated image veya PDF,
• AI summary çıktısı,
• Static search index,
• Sitemap veya feed cache’i,
• Feature/config JSON,
• Function’ın sonraki çalışmada okuyacağı output,
• Büyük text veya binary object,
• Build ile oluşturulan deploy-specific data.

Şu sorular baskınsa Database düşünün:

• “Status’u pending olan tüm kayıtları filtrele.”
• “User ile order arasında ilişki kur.”
• “Birden fazla kaydı atomik değiştir.”
• “Aynı kaydı eş zamanlı update ederken conflict çöz.”
• “Aggregate ve ad hoc rapor üret.”

Blobs list/prefix üzerinden object discovery sunar; query engine sunmaz.

Paket Nasıl Kurulur?

``bash npm install @netlify/blobs ``

Güncel Node. js runtime’da Fetch API gerekir. Netlify dokümanı Node 18 ve sonrası için built-in fetch bulunduğunu belirtir. Daha eski veya özel runtime’da fetch implementation ayrıca verilebilir; production’da desteklenen runtime kullanmak daha basittir.

Temel Function yapısı:

``text my-project/ ├── netlify/ │ └── functions/ │ ├── blob-write.mts │ ├── blob-read.mts │ └── blob-list.mts ├── package.json └── netlify.toml ``

Yerel geliştirme:

``bash netlify link netlify dev ``

Netlify Dev, production data’yı otomatik indirmek yerine local sandbox store kullanır. Yerelde yazılan object’ler production store’a gitmez. Bu izolasyon güvenlidir; fakat production’daki gerçek data ile parity gerektiğinde anonim sentetik fixture hazırlamak gerekir.

Store Nasıl Açılır?

Site-wide store:

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

const reports = getStore("reports"); ```

Strong consistency store:

``ts const reports = getStore({ name: "reports", consistency: "strong" }); ``

Store adı kısa, anlamlı ve PII içermeyen bir namespace olmalıdır. Tenant veya user e-postasını store adına yazmak yerine key veya authorization metadata’sında opaque ID kullanın.

Site-wide store, aynı site içindeki production, Deploy Preview ve Branch Deploy gibi context’lerden erişilebilir olabilir. Bu kolaylık, preview code’un production object’ini değiştirmesi riskini de getirir. Environment’a göre ayrı store adı veya deploy-specific store kullanın.

String ve JSON Nasıl Yazılır?

String:

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

const store = getStore("notes");

await store. set("welcome", "Merhaba Netlify Blobs"); ```

JSON:

``ts await store.setJSON("tasks/demo-001", { id: "demo-001", title: "Blobs dokümanını doğrula", status: "open", updatedAt: new Date().toISOString() }); ``

Metadata ile:

``ts await store.setJSON( "tasks/demo-001", { id: "demo-001", title: "Blobs dokümanını doğrula", status: "open" }, { metadata: { schemaVersion: 1, contentType: "task" } } ); ``

Metadata toplam boyutu 2 KB ile sınırlıdır. Büyük açıklama, raw prompt veya user profile gibi content metadata’ya değil value içine konmalıdır. Metadata’yı auth source of truth olarak kullanmadan önce object erişim kontrolünü ayrıca yapın.

Object key tasarımı:

``text tasks/demo-001 reports/2026/08/daily-23.json uploads/user_8f12/avatar.webp ai-summaries/submission_batch_03/v2.json ``

Key’de gerçek e-posta, telefon veya kimlik numarası kullanmayın. Log, URL veya list output’unda görülebilir.

Veriler Nasıl Okunur?

String:

```ts const value = await store.get("welcome");

if (value === null) { return new Response("Not found", { status: 404 }); } ```

JSON:

``ts const task = await store.get("tasks/demo-001", { type: "json" }); ``

Binary/ArrayBuffer veya stream ihtiyacında type seçeneği güncel API dokümanına göre belirlenir.

Metadata ile birlikte:

```ts const entry = await store.getWithMetadata("tasks/demo-001", { type: "json" });

if (entry === null) { return Response. json({ error: "Not found" }, { status: 404 }); }

return Response. json({ data: entry. data, metadata: entry. metadata, etag: entry. etag }); ```

ETag object version/fingerprint gözlemi için kullanılabilir. Blobs built-in conditional write veya concurrency control garantisi sunmadığından ETag’i yalnız uygulama düzeyinde conflict stratejisiyle kullanın.

Strong read operation örneği:

``ts const latest = await store.get("tasks/demo-001", { type: "json", consistency: "strong" }); ``

API’nin exact option biçimi package sürümünde TypeScript ile doğrulanmalıdır.

Dosya Nasıl Saklanır?

Function request body’sini doğrudan object olarak yazabilirsiniz:

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

const MAX_FILE_SIZE = 5 1024 1024;

export default async (request: Request) => { if (request. method ! == "PUT") { return Response. json( { error: "Method not allowed" }, { status: 405, headers: { Allow: "PUT" } } ); }

const contentType = request. headers. get("content-type") ?? ""; const allowed = ["image/png", "image/jpeg", "image/webp"];

if (! allowed. includes(contentType)) { return Response. json({ error: "Unsupported file type" }, { status: 415 }); }

const body = await request. arrayBuffer();

if (body. byteLength === 0 || body. byteLength > MAX_FILE_SIZE) { return Response. json({ error: "Invalid file size" }, { status: 413 }); }

const key = uploads/${crypto. randomUUID()}; const store = getStore("uploads");

await store. set(key, body, { metadata: { contentType } });

return Response. json({ key }, { status: 201 }); };

export const config: Config = { path: "/api/uploads" }; ```

Bu örnek yalnız temel type/size kontrolüdür. Production file upload için:

• Authentication ve ownership,
• Magic-byte/MIME doğrulama,
• Malware scan,
• Image/PDF parser güvenliği,
• Download content disposition,
• Public/private erişim,
• Rate limit ve quota,
• PII retention,
• Filename ve metadata sanitization

gerekir.

Blobs object üst sınırı 5 GB olsa da Function request body, execution time, memory ve network limitleri daha düşük olabilir. Büyük upload için resumable/direct upload veya özel object storage akışı gerekebilir.

Object’ler Nasıl Listelenir?

Tüm key’ler:

```ts const { blobs } = await store.list();

return Response. json({ count: blobs. length, keys: blobs. map((blob) => blob. key) }); ```

Prefix:

``ts const { blobs } = await store.list({ prefix: "reports/2026/08/" }); ``

Directory benzeri ayrım:

``ts const { blobs, directories } = await store.list({ prefix: "reports/", directories: true }); ``

Büyük store için pagination:

```ts let total = 0;

for await (const page of store. list({ paginate: true })) { total += page. blobs. length; } ```

List API, SQL query değildir. Key prefix’i veri erişim desenine göre tasarlayın. user/{id}/... kullanıyorsanız endpoint’te authenticated user ile key prefix’in eşleştiğini doğrulayın; client’tan gelen arbitrary prefix’e güvenmeyin.

Key listesi de hassas olabilir. Object içeriğini döndürmeseniz bile dosya adı veya tenant ID bilgi sızdırabilir.

Update ve Delete Nasıl Yapılır?

Update, aynı key’e yeni value yazmaktır:

``ts await store.setJSON("tasks/demo-001", { id: "demo-001", title: "Blobs dokümanını doğrula", status: "done", updatedAt: new Date().toISOString() }); ``

Aynı key’e eş zamanlı iki write yapılırsa son write kazanır. Blobs native lock veya compare-and-swap sunmaz. Race condition önemliyse:

• Database transaction kullanın,
• Uygulama-level version/lock object’i tasarlayın,
• Write’ları queue/tek worker üzerinden serialize edin,
• Immutable versioned key üretip pointer’ı kontrollü değiştirin.

Delete:

``ts await store.delete("tasks/demo-001"); ``

Tüm store’u silmek:

``ts const { deletedBlobs } = await store.deleteAll(); ``

deleteAll production’da büyük etki yaratır. Admin Function’a koyacaksanız güçlü authorization, environment guard, audit ve iki aşamalı confirmation uygulayın. Preview’ın production site-wide store’una erişmediğini doğrulayın.

Eventual ve Strong Consistency Arasındaki Fark

Varsayılan eventual consistency modelinde:

• Yeni object eklendiğinde global olarak hemen erişilebilir.
• Existing object update ve delete değişiklikleri edge noktalarına 60 saniye içinde yayılır.
• Read daha hızlı olabilir.

Strong consistency:

• Update/delete sonrası en güncel version’ı okumaya yöneliktir.
• Store veya operation seviyesinde seçilebilir.
• Daha yavaş read trade-off’u olabilir.
• Netlify CLI her zaman strong consistency kullanır.

Seçim örnekleri:

Senaryo	Tercih
Versioned immutable image	Eventual
Generated report, key her sürümde yeni	Eventual
Kullanıcı profile JSON update sonrası hemen oku	Strong veya Database
Feature flag anlık değişmeli	Strong; audit/concurrency için Database değerlendir
Cache benzeri public API sonucu	Eventual
Balance/stock	Blobs yerine Database transaction

Eventual consistency testinde update sonrası aynı region’dan tek read yapmak yeterli değildir. Farklı edge konumlarından polling yapıp body version ve timestamp kaydedin.

Site-Wide ve Deploy-Specific Store Farkı

Site-wide store

``ts const store = getStore("content-cache"); ``

• Deploy’lar arasında kalıcıdır.
• Farklı deploy context’lerinden erişilebilir.
• Production iş verisi, persistent upload ve shared cache için kullanılabilir.
• Preview’ın production object’ine erişme riski vardır.

Deploy-specific store

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

const store = getDeployStore("generated-assets"); ```

• Belirli deploy’a bağlıdır.
• Function, Edge Function ve Build Plugin’den erişilebilir.
• Rollback’te relative deploy ile birlikte hareket eder.
• Automatic deploy deletion lifecycle’ında temizlenebilir.
• Failed build’in production data’yı overwrite etmesini önlemeye yardımcı olur.
• Deploy download işlemi deploy-specific blobs’u otomatik indirmeyebilir.

Build plugin ve file-based upload’lar deploy-specific store kullanmalıdır. Build sırasında . netlify/blobs/deploy dizinine oluşturulan files deploy’la ilişkilendirilir; build başlamadan önce bu dizindeki mevcut files temizlenir. Kaynak asset’i bu klasöre önceden koyup kalıcı kalmasını beklemeyin.

Deploy-specific store şu içerikler için idealdir:

• Build-generated search index,
• Deploy’a ait transformed asset,
• Static page manifest,
• Preview-specific demo data,
• Atomik deploy ile birlikte rollback olması gereken object.

Kullanıcı upload’ı veya kalıcı business record deploy deletion ile kaybolmamalıysa site-wide store veya başka persistent storage seçin.

Blobs Güvenliği Nasıl Sağlanır?

Blobs store’a erişen Function veya Edge Function, authorization sınırıdır. Key’in tahmin edilmesi zor olması erişim kontrolü yerine geçmez.

Örnek ownership kontrolü:

``ts const user = await requireAuthenticatedUser(request); const requestedKey = context.params.key; const expectedPrefix = users/${user.id}/`;

if (! requestedKey. startsWith(expectedPrefix)) { return Response. json({ error: "Forbidden" }, { status: 403 }); } ```

Kontroller:

• Kullanıcı authenticate edildi mi?
• Bu key/store için authorization var mı?
• List prefix kullanıcı scope’uyla sınırlı mı?
• Upload type ve size doğrulanıyor mu?
• Object response doğru Content-Type ve Content-Disposition içeriyor mu?
• Secret veya PII key/metadata/log içine yazılıyor mu?
• Preview production site-wide store’a yazabiliyor mu?
• Delete endpoint’i role ve environment guard içeriyor mu?
• Retention ve user deletion isteği uygulanabiliyor mu?

Netlify Blobs güncel dokümana göre HIPAA-compliant hosting kapsamına dahil değildir. Sağlık verisi gibi regulated workload’da yalnız encryption veya private Function yeterli kabul edilmemelidir; hizmetin resmi compliance kapsamı ve sözleşme şartları incelenmelidir.

Limitler ve Tasarım Sonuçları

23 Ağustos 2026 tarihli resmî dokümana göre:

Limit	Değer
Store adı	64 byte
Key	600 byte
Tek object	5 GB
Metadata	2 KB
Empty key	Desteklenmez
Key başlangıcı	/ olamaz

Bu limitler “uygulama için ideal boyut” değil teknik üst sınırlardır. 4,9 GB upload’ın Function memory/time limiti içinde sorunsuz olacağı anlamına gelmez. Büyük object için transfer, retry, partial upload, virus scanning ve bandwidth maliyeti planlanmalıdır.

Blobs pricing/usage davranışı hesap türü ve güncel planla doğrulanmalıdır. Object boyutu, read/write/list sıklığı, Functions compute ve bandwidth birlikte aylık maliyeti etkiler.

Netlify Blobs Ne Zaman Kullanılmamalı?

Şu durumlarda Database veya başka storage düşünün:

• Complex filtreleme ve sorting,
• Frequent partial updates,
• Multi-record transaction,
• Strong concurrency control,
• Full-text search,
• High write contention,
• Query-based analytics,
• HIPAA kapsamındaki workload,
• Event streaming veya queue semantiği,
• Çok büyük resumable upload gereksinimi,
• Object lifecycle ve replication üzerinde ayrıntılı cloud-level control.

Blobs simple API sunduğu için her veriyi JSON object’e dönüştürmek başlangıçta hızlı görünür. Veri modeli büyüdüğünde list edip uygulama kodunda filtrelemek maliyetli migration yaratır. Query pattern’i en başta yazın.

20 Object’lik Zorunlu Test

Sentetik test dataset’i:

• 10 JSON record,
• 8 text object,
• 1 küçük PNG fixture,
• 1 küçük PDF fixture,
• Toplam 20 object.

Test akışı:

Adım	İşlem	Ölçüm
1	20 write	Success/error, duration, object size
2	20 eventual read	Body hash, duration
3	20 strong read	Body hash, duration
4	Prefix list	Count, pagination, key order
5	5 update	Version, propagation time
6	5 strong update read	Latest version doğruluğu
7	5 delete	Eventual görünürlük süresi
8	2 file download	Hash, content type, size
9	Site-wide vs deploy store	Cross-context visibility
10	Rollback	Deploy-specific object uyumu

Her object için random opaque key, SHA-256 body hash ve byte size kaydedilmelidir. Test gerçek kişisel data veya executable file içermemelidir.

> Editör notu — zorunlu özgün kanıt: Bu taslak hazırlanırken 20 object Netlify Blobs’a yazılmadı; eventual/strong read, update propagation, delete veya deploy-specific rollback testi yapılmadı. Yayından önce yalnız sentetik fixture’larla test uygulanmalı; Node, CLI ve @netlify/blobs sürümü, commit/deploy ID, region, consistency mode, object byte size, hash ve ham zamanlar kaydedilmelidir. Küçük test sonucu evrensel performans iddiası olarak sunulmamalıdır.

> Görsel notu: Store → key → value/metadata modeli, eventual vs strong read yolu ve site-wide vs deploy-specific lifecycle için üç özgün diyagram hazırlanmalıdır.

> İç link editör notu: Netlify Storage, Database, Functions ve AI form özetleme yazıları yayımlandığında ilgili karar ve uygulama bölümlerine doğal bağlantı eklenmelidir.

Netlify Blobs Kontrol Listesi

• [ ] Veriye key üzerinden erişim gerçekten yeterli.
• [ ] SQL, transaction ve high-write contention gerekmiyor.
• [ ] Store adı ve key PII içermiyor.
• [ ] Site-wide/deploy-specific scope bilinçli seçildi.
• [ ] Preview production object’ine yazamıyor.
• [ ] Eventual/strong consistency gereksinimi belirlendi.
• [ ] File upload’da auth, type, size ve malware kontrolü var.
• [ ] List endpoint’i tenant/user prefix’iyle sınırlandırıldı.
• [ ] Last-write-wins race condition kabul edildi veya yönetildi.
• [ ] Delete/deleteAll güçlü authorization içeriyor.
• [ ] Limit ve compliance kapsamı doğrulandı.
• [ ] 20 object’lik sentetik test raporlandı.

Sık Sorulan Sorular

Netlify Blobs bir database mi?

Basit key-value/object store olarak veri saklar; SQL, join, transaction ve ilişkisel schema sunmaz. Complex query için Netlify Database kullanılır.

Blobs verisi Deploy Preview’dan görülebilir mi?

Site-wide store farklı deploy context’lerinden erişilebilir. Preview için ayrı store/prefix, read-only policy veya deploy-specific store kullanarak production izolasyonu tasarlayın.

Netlify Blobs strong consistency sunuyor mu?

Evet. Store veya read operation seviyesinde strong consistency seçilebilir. Varsayılan eventual model daha hızlı read sunabilir; update/delete değişiklikleri edge’e 60 saniye içinde yayılır.

Tek object en fazla kaç GB olabilir?

23 Ağustos 2026 itibarıyla resmî limit 5 GB’dır. Function request, memory, time ve network limitleri daha düşük pratik sınır oluşturabilir.

Dosya upload için güvenli mi?

Storage katmanı sağlar; authentication, authorization, malware/type validation, privacy ve retention uygulama tarafından eklenmelidir. HIPAA-compliant hosting kapsamına dahil değildir.

Kaynaklar

• Netlify Blobs overview
• Blobs API reference
• Blobs security
• Data and Storage overview
• Functions overview
• Netlify Blobs product page

Sonuç

Netlify Blobs, file ve key-value data’yı Netlify deploy/compute akışına yakın biçimde saklamak için yalın bir object storage katmanıdır. Sağlam kullanım için key tasarımını erişim desenine göre kurun, site-wide ve deploy-specific store farkını bilin, eventual consistency’yi varsayılan kabul edip doğruluk gereken read’lerde strong modu değerlendirin. Blobs’u ilişkisel database yerine zorlamayın; last-write-wins ve query sınırlamaları business data için önemli trade-off’lardır. File ve PII kullanımında authorization, validation, retention ve compliance sınırlarını ayrıca yönetin.

Dosya ve key-value verilerinizi Netlify Blobs ile 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.