SQLite mi PostgreSQL mi: geçiş zamanı ne zaman gelir

n8n varsayılan olarak SQLite ile başlar; bu, kendi sunucu sürecine sahip olmayan ve ayrı bir kurulum gerektirmeyen bir dosya veritabanıdır. Test örnekleri, tek tük otomasyonlar ve başlangıç için bu yeterlidir. Ancak birden fazla eşzamanlı workflow çalıştırmaya, kuyruk modunu kullanmaya veya birden fazla main örneği işletmeye başladığınızda, n8n kendi dokümantasyonunda açıkça 13. sürümden itibaren PostgreSQL öneriyor. Geçiş için doğru zaman, sabit bir kullanıcı sayısından çok üç faktöre bağlıdır: eşzamanlı çalıştırma sayısı, planlanan mimari ve loglarda kilit hatalarının ne sıklıkta ortaya çıktığı. Güncelleme: Temmuz 2026.

SQLite'ın sınırlarına ulaştığının belirtileri

n8n topluluğunda tekrar tekrar aynı hata görülüyor: SQLITE_BUSY: database is locked. Bunun nedeni, bir dosya için aynı anda yalnızca bir yazma erişimine izin veren SQLite tasarımıdır. Birden fazla workflow paralel çalışıyorsa veya aktif çalıştırmalar sırasında editörü açarsanız, aynı dosyaya yazma erişimleri çakışır. Kısa vadede, en az 5000 milisaniyelik bir meşgul zaman aşımı (busy timeout) ile WAL modu (Write-Ahead Logging) yardımcı olur ve hata sıklığını azaltır. Ancak bunun temelindeki tek yazıcı sınırlaması bundan etkilenmez ve yük arttıkça güvenilir şekilde geri döner.

n8n'in kendisinin belirttiği eşik değerleri

n8n, dokümantasyonunda geçiş noktası olarak sabit bir günlük çalıştırma sayısı belirtmez, bunun yerine sınırı somut mimari kararlara bağlar.

• Kuyruk modu planlanıyor: n8n, üretim ortamında kuyruk modu için doğrudan şunu belirtir: SQLite veritabanıyla queue çalıştırma modu önerilmez. Worker süreçleri aynı veritabanına paralel olarak yazmaya başladığında Postgres gerekli hale gelir.
• Birden fazla main örneği (multi-main): Birden fazla main süreciyle yüksek erişilebilirlik için n8n açıkça Postgres ve Redis bağlantısı gerektirir; SQLite bunun için tasarlanmamıştır.
• Worker eşzamanlılığı: Worker başına eşzamanlılık (concurrency) değeri varsayılan olarak 10'dur, n8n en az 5 önerir. Dokümantasyona göre düşük eşzamanlılıkla çalışan çok sayıda worker'da veritabanı bağlantılarının tükenmesi riski vardır; gerçek bir bağlantı havuzu olmayan tek dosyalık bir veritabanı bu durumu yapısal olarak zayıf şekilde karşılar.
• Benchmark'tan referans değer: Resmi performans testlerinde, Postgres arka uçlu tek bir örnek saniyede 220'ye kadar workflow çalıştırmasına ulaşır. Bu bir SQLite sınırı değildir, ancak n8n'de Postgres'in hangi yük sınıfı için tasarlandığını gösterir.
• n8n Cloud'dan sinyal: n8n kendi bulut ürününde bile Postgres'i yalnızca Enterprise Scaling planlarına ayırır, tüm daha küçük katmanlar SQLite üzerinde çalışır. Bu, n8n'in geçişi ne zamandan itibaren gerekli gördüğünü yaklaşık olarak yansıtır.

SQLite'tan PostgreSQL'e geçiş adımları

Geçiş, veritabanı dosyasının otomatik dönüştürülmesi yoluyla değil, dışa aktarma ve içe aktarma yoluyla yapılır.

• PostgreSQL'i hazırlayın: Postgres 13 veya daha yenisini kurun, kendine ait bir veritabanı ve bunun üzerinde tam yetkilere sahip özel bir kullanıcı oluşturun.
• Workflow'ları ve credentials'ı dışa aktarın: CLI üzerinden n8n export:workflow --all --output=backup/ ve n8n export:credentials --all --decrypted --output=backup/ komutlarıyla yedekleyin. Şifresi çözülmüş credentials yedeği, hemen ardından korumalı ve herkese açık olmayan bir konuma taşınmalıdır.
• Ortam değişkenlerini değiştirin: DB_TYPE değerini postgresdb olarak ayarlayın ve ilgili DB_POSTGRESDB değişkenleri aracılığıyla host, port, veritabanı adı, kullanıcı, parola ve isteğe bağlı olarak şemayı yapılandırın.
• n8n'i boş Postgres veritabanına karşı başlatın: n8n, ilk başlatmada gerekli şemayı kendisi oluşturur; tabloları manuel olarak oluşturmaya gerek yoktur.
• Verileri geri yükleyin: n8n import:workflow --separate --input=backup/ ve n8n import:credentials --separate --input=backup/ komutlarıyla yedeklenen durumları geri yükleyin ve ardından workflow'ları örnekleme yoluyla test edin.

Geçişin gerektirdiği çaba ve sınırları

Geçiş tek tıkla yapılan bir işlem değil, küçük bir bakım penceresidir: dışa aktarma, yeniden yapılandırma ve içe aktarma sırasında n8n kısa süreliğine durur ve ayrıntılı çalıştırma geçmişleri standart yöntemle otomatik olarak taşınmaz. Az sayıda workflow içeren küçük kurulumlarda çaba sınırlıdır; çok sayıda aktif otomasyonu olan büyümüş örneklerde önceden bir staging örneği üzerinde test yapmak faydalıdır. Bu adımın sorumluluğunu canlı ortamda tek başına üstlenmek istemeyenler, sabit fiyatlı bir n8n danışmanlığı kapsamında dışarıdan destek de alabilir.

n8n'de SQLite ve PostgreSQL hakkında sık sorulan sorular

Günde kaç çalıştırmadan itibaren PostgreSQL'e geçmem gerekir?

n8n net bir rakam vermez. Dokümantasyona göre belirleyici olan daha çok mimaridir: kuyruk modu veya birden fazla main örneği planlandığı anda, tam çalıştırma hacminden bağımsız olarak Postgres bir ön koşul haline gelir.

SQLite'ı kullanmaya devam edip yalnızca busy timeout değerini artırabilir miyim?

Az paralellik içeren küçük örnekler için evet, bu kilit hatalarını gözle görülür şekilde azaltabilir. Ancak kuyruk moduna veya multi-main'e yöneldiğinizde, n8n'e göre bu ayar artık yeterli olmaz.

Geçiş sırasında veri kaybı yaşanır mı?

Dışa ve içe aktarma yoluyla standart yöntem, workflow'ları ve credentials'ı güvenilir şekilde aktarır. Eksiksiz çalıştırma geçmişleri buna otomatik olarak dahil değildir; buna ihtiyaç duyanlar geçişten önce bunu ayrıca kontrol etmelidir.

PostgreSQL için kesinlikle kuyruk moduna ihtiyacım var mı?

Hayır. PostgreSQL'i, örneğin kilit hatalarından kaçınmak için, kuyruk modu olmadan single-main modda da kullanabilirsiniz. Kuyruk modu ve multi-main, ayrıca Redis gerektiren ayrı genişletme aşamalarıdır.

Veritabanı seçimi ve ortam değişkenleri hakkında daha fazla ayrıntıyı n8n'in veritabanı seçimi dokümantasyonunda ve kuyruk modu kılavuzunda bulabilirsiniz.