KOBİ'ler için Otomasyon Yığını: n8n, Veritabanı, Vector Store ve Monitoring Genel Bakış

n8n'i tek bir proje için kuran biri genellikle tek bir örnek (instance) ve birlikte gelen SQLite veritabanıyla idare eder. Ancak proje, birden çok paralel workflow, artan veri hacmi ve şirket bilgisine erişen yapay zeka (YZ) ajanlarıyla birlikte tüm bir şirket için üretimde kullanılan bir otomasyon yığınına dönüştüğünde, bu minimal yapılandırma artık yetmez. O zaman hangi bileşenlerin gerçekten birbirine ait olduğu sorusu ortaya çıkar: veritabanı, kuyruk, vector store ve monitoring isteğe bağlı ekstralar değil, bir test kurulumunu dayanıklı bir platforma dönüştüren yapı taşlarıdır.

Bu makale, ölçeklendirme, veritabanı ve işletim konularındaki resmi n8n dokümantasyonuna dayanarak genel tabloyu gösteriyor. Güncelleme: Temmuz 2026.

Tek bir n8n örneği neden üretim için yeterli değildir

Standart işletimde n8n, tetikleyicileri alan, workflow'ları yürüten ve sonuçları doğrudan kendi veritabanına yazan tek bir örnek olarak çalışır. Küçük ekipler ve az sayıda workflow için bu güvenilir bir şekilde işler. Ancak birden fazla hesaplama yoğun workflow aynı anda çalıştığında veya kısa sürede çok sayıda webhook geldiğinde, bu tek örnek bir darboğaz haline gelir: hem tetikleyicileri almak, hem çalıştırmaları (execution) yönetmek hem de asıl yürütmeyi üstlenmek zorundadır. n8n'in ölçeklendirmeyle ilgili dokümantasyonuna göre, tam olarak bu görevleri birden fazla örneğe dağıttığı için en iyi ölçeklenebilirliği kuyruk modu (queue mode) adı verilen yapı sunar. Test aşamasını aşan bir KOBİ yığını için tek örnekli işletimden kuyruk moduna geçiş, bu nedenle genellikle ilk yapısal adımdır.

Veritabanı: PostgreSQL neden temel taşıdır

n8n varsayılan olarak kimlik bilgilerini, geçmiş çalıştırmaları ve workflow'ları saklamak için SQLite kullanır. Bu, hızlı bir başlangıç için pratiktir ancak eşzamanlı erişimlerde ve artan veri hacminde sınırlarına ulaşır. Üretim ortamları için n8n'in veritabanı seçimiyle ilgili dokümantasyonu PostgreSQL'e geçişi önerir; bu, `DB_TYPE=postgresdb` gibi ortam değişkenleri üzerinden yapılandırılır. Yetki yönetimi için önemli olan: n8n, kullanılan tabloların şemalarını kendisi oluşturabilmeli ve değiştirebilmelidir, bu nedenle veritabanı kullanıcısına buna uygun geniş yetkiler tanınmalıdır. PostgreSQL böylece yalnızca çok sayıda eşzamanlı workflow için daha sağlam bir seçim değil, aynı zamanda bir sonraki yapı taşı için de zorunlu bir ön koşuldur.

Kuyruk modu: Ana örnek, worker'lar ve kuyruk olarak Redis

Kuyruk modu sorumlulukları net bir şekilde ayırır. Kuyruk modunu etkinleştirme kılavuzuna göre, ana örnek zamanlayıcıları ve webhook çağrılarını üstlenir ve bunlardan bir çalıştırma (execution) oluşturur, ancak bunu kendisi yürütmez. Bunun yerine çalıştırma kimliğini (execution ID), kuyruğu bir mesaj aracısı (message broker) olarak yöneten Redis'e iletir. Her biri kendi Node.js süreci olan worker örnekleri, görevleri bu kuyruktan alır ve asıl workflow'ları yürütür. Bir KOBİ yığını için bu somut olarak şu anlama gelir:

• İhtiyaç halinde daha fazla yükü işlemek için ek worker'lar kolayca eklenebilir ve talep azaldığında yeniden kaldırılabilir.
• SQLite bu işletim modu için açıkça önerilmez; PostgreSQL 13. sürümden itibaren temeldir.
• Ana örnek ve worker'lar dahil tüm örnekler, kimlik bilgilerinin her yerde çözülebilmesi için aynı şifreleme anahtarını kullanmalıdır.
• `EXECUTIONS_MODE=queue` ortam değişkeni, ilgili tüm örneklerde ayarlanmış olmalıdır.

Sadece ara sıra tekil workflow'lar çalıştıran biri bu çabaya hemen ihtiyaç duymaz. Ancak birden çok departman aynı n8n yığınını üretimde kullanmaya başladığında, ana örnek ve worker'lara ayrılmak hızla karşılığını verir.

Vector store: Şirket bilgisini YZ ajanları için aranabilir hale getirmek

Bir otomasyon yığını yalnızca klasik workflow'ları değil, aynı zamanda şirket bilgisine erişen YZ ajanlarını da desteklemesi gerektiğinde, devreye başka bir yapı taşı girer: bir vector store. Zaten PostgreSQL kullanan ekipler için, PGVector node ile ilgili dokümantasyona göre bariz bir çözüm sunulur: PGVector eklentisi, halihazırda n8n veritabanı olarak çalışan aynı PostgreSQL örneğini aynı zamanda bir vektör veritabanına dönüştürür. Bu node, belgeleri bir vektör tablosuna eklemeyi, hedefli şekilde almayı ve doğrudan bir araç olarak bir YZ ajanına bağlamayı mümkün kılar, örneğin iç belgelerle ilgili soruları yanıtlayan bir bilgi asistanı için. Alternatif olarak n8n, vektör aramasının operasyonel workflow veritabanından bilinçli olarak ayrılması gerektiğinde, örneğin performans veya ölçeklendirme nedenleriyle, Qdrant, Weaviate veya Supabase gibi özel vector store'ları da destekler. Sade bir KOBİ yığını için ortak PostgreSQL çözümü, kendi başına bir vector store hizmeti gerçekten gerekli olmadan önce genellikle daha pragmatik bir başlangıç noktasıdır.

Monitoring ve loglama: Canlı işletimde görünürlük

Birden fazla dağıtık bileşenden oluşan bir yığın, ancak üzerindeki görünürlük kadar iyidir. n8n'in monitoring ile ilgili dokümantasyonu tam olarak bunun için tasarlanmış üç uç nokta (endpoint) açıklar:

• `/healthz`, HTTP 200 ile örneğin erişilebilir olduğunu bildirir, ancak veritabanı durumu hakkında hiçbir şey söylemez. Ana sunucularda varsayılan olarak etkindir.
• `/healthz/readiness`, ancak veritabanı bağlandığında ve tüm migration'lar tamamlandığında HTTP 200 döndürür; bu, örneğin trafiği kabul edebileceğine dair çok daha anlamlı bir göstergedir.
• `/metrics`, Prometheus formatında ayrıntılı ölçümler sağlar, ancak varsayılan olarak devre dışıdır ve n8n Cloud üzerinde hiç kullanılamaz. `N8N_METRICS=true` üzerinden etkinleştirilir, worker sağlık kontrolleri için ayrıca `QUEUE_HEALTH_CHECK_ACTIVE=true` üzerinden de etkinleştirilir.

Buna ek olarak, loglama ile ilgili dokümantasyon, n8n'in ne kadar ayrıntılı log tuttuğunu belirler. `N8N_LOG_LEVEL` üzerinden seviye `silent`'ten `debug`'a kadar ayarlanabilir, varsayılan `info`'dur. `N8N_LOG_OUTPUT` üzerinden logların konsola, bir dosyaya veya her ikisine birden yazılıp yazılmayacağını belirlersin; buna `N8N_LOG_FILE_LOCATION` ile dosya boyutu ve saklanan dosya sayısı için sınırlar da eklenir. Özellikle birden fazla worker sürecinin bulunduğu kuyruk modunda, düzgün bir log rotasyonu sadece güzel bir ekstra değil, bir hata durumunda hangi worker'ın hangi çalıştırmayı ne zaman işlediğini anlayabilmenin ön koşuludur.

Genel tablo: Hangi bileşenler gerçekten birbirine ait

Özetle, n8n etrafında üretime hazır bir KOBİ otomasyon yığını, birbirinin üzerine inşa edilen birkaç katmandan oluşur:

• n8n Ana örneği tetikleyiciler, webhook'lar ve web arayüzü için.
• PostgreSQL workflow'lar, kimlik bilgileri ve çalıştırma geçmişi için merkezi veritabanı olarak, 13. sürümden itibaren ve yeterli şema yetkileriyle.
• Redis birden fazla worker ile kuyruk modu kullanıldığında kuyruk olarak.
• n8n Worker'ları asıl yürütme için, gerçek talebe göre yatay olarak ölçeklenebilir.
• Vector store, ister aynı PostgreSQL örneğinin bir PGVector eklentisi olarak ister özel bir hizmet olarak, YZ ajanları şirket bilgisine erişmesi gerektiğinde.
• Monitoring ve loglama `/healthz`, `/healthz/readiness` ve `/metrics` uç noktaları ile yapılandırılmış loglar üzerinden, böylece işletim bir hata durumunda izlenebilir kalır.

Her şirketin başından itibaren tüm katmanlara aynı anda ihtiyacı yoktur. Çoğu KOBİ için mantıklı yol, sağlam bir temel olarak PostgreSQL ile başlamak, yük bunu haklı çıkardığında kuyruk modunu eklemek ve monitoring'i sonradan eklemek yerine baştan itibaren düşünmektir. Böylece yığın, gerçek gereksinimlerle birlikte büyür ve gerçek sorundan daha büyük bir mimari inşa etmek yerine maliyet, karmaşıklık ve işletim riski üzerinde kontrolü elinde tutarsın. NordFlux'ta, n8n danışmanlığımız kapsamında tam olarak bu kurulumu, ilk sunucu kurulumundan monitoring ve SLA ile işletime kadar planlıyoruz. YZ ajanlarının şirket içi bilgiye erişmesi gerektiği yerlerde, YZ Bilgi Asistanımız bunun için gereken tam olarak vector store bileşenini ekler.

Sıkça Sorulan Sorular

n8n'in üretimde çalıştırılması için SQLite yeterli mi?

Ek altyapı gerektirmeden çalıştığı için, tekil ve düşük trafikli workflow'lar için SQLite yeterli olabilir. Birden fazla workflow paralel çalıştığında veya kuyruk modu kullanıldığında, n8n dokümantasyonu SQLite'ın dağıtık yürütme için tasarlanmadığından açıkça PostgreSQL'e geçişi önerir.

Bir KOBİ yığını için hemen birden fazla worker ile kuyruk moduna ihtiyacım var mı?

Mutlaka değil. Kuyruk modu, birden fazla hesaplama yoğun workflow aynı anda çalıştığında veya kısa sürede çok sayıda webhook geldiğinde ve tek bir örnek darboğaz haline geldiğinde işe yarar. Az sayıda yönetilebilir workflow içeren daha küçük kurulumlar için genellikle arka planda PostgreSQL ile tek bir ana örnek yeterlidir.

Bir n8n yığınının neden bir vector store'a ihtiyacı var?

Bir vector store, n8n'deki YZ ajanlarının belgeler, kılavuzlar veya destek geçmişleri gibi şirket içi bilgilere erişmesi gerektiğinde önem kazanır. Vector store, bu içeriği aranabilir bir biçimde saklar; böylece bir ajan, bir sorguda yalnızca eğitim bilgisiyle çalışmak yerine uygun metin parçalarını bulur ve yanıtına dahil eder.

`/healthz` ve `/healthz/readiness` birbirinden nasıl ayrılır?

`/healthz` yalnızca n8n örneğinin temel olarak erişilebilir olup olmadığını kontrol eder, ancak veritabanı hakkında hiçbir şey söylemez. `/healthz/readiness` bir adım daha ileri gider ve yalnızca veritabanı bağlantısı kurulduğunda ve tüm migration'lar tamamlandığında başarı bildirir. Bu nedenle Kubernetes veya Docker kurulumları için genellikle readiness uç noktası, bir örneğin gerçekten trafik kabul etmesi gerekip gerekmediğine dair daha anlamlı göstergedir.

Otomasyon yığınını hepsini bir kerede değil, adım adım oluşturabilir miyim?

Evet, ve bu çoğu KOBİ için daha da tavsiye edilen yoldur. Gerçekçi bir sıra, bir PostgreSQL veritabanıyla başlamak, monitoring'i baştan itibaren kurmak, kuyruk modunu ancak yük arttığında eklemek ve bir vector store'u ancak şirket bilgisine erişimi olan bir YZ ajanı gerçekten planlandığında eklemektir.