Üretime hazır bir n8n otomasyon yığınının KOBİ'ler için ihtiyaç duyduğu bileşenler: veritabanı, kuyruk modu, vector store ve monitoring bir bakışta.
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.
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.
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 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:
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.
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.
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.
Özetle, n8n etrafında üretime hazır bir KOBİ otomasyon yığını, birbirinin üzerine inşa edilen birkaç katmandan oluşur:
/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.
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.
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 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.
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.
NordFlux'un kurucusu. Webden ve SEO'dan grup ölçeğindeki otomasyona kadar yedi yıllık deneyim, bugün KOBİ'ler için pragmatik biçimde ve Alman veri egemenliğiyle.
Sertifikalar
n8n'deki RAG ajanlarının vector store'u neden görmezden geldiğine dair en sık 5 neden: embedding, chunking, filtreler, prompt ve araç çıktısı bir bakışta.
Log seviyesi, /healthz uç noktası ve Prometheus metrikleri: Kendi barındırdığınız n8n örneğini güvenilir şekilde nasıl izlersiniz.
n8n ile RAG chatbot nasıl kurulur: Vector Store, embedding'ler ve araç bağlantısı adım adım anlatılıyor.
Tek tek bileşenler iyi belgelenmiş olsa da üretim ortamında n8n instance'ınızın dayanıp dayanamayacağını veritabanı, kuyruk, vector store ve izlemenin birlikte nasıl çalıştığı belirler. NordFlux bu yığını sizin için planlar ve işletir, PostgreSQL bağlantısından canlı ortamdaki uyarılara kadar. İlk görüşmede ölçeğinize göre hangi bileşenlere gerçekten ihtiyacınız olduğunu birlikte belirleriz.