Telegram Serverless, SQLite'de VPS'lerin gerisinde kalıyor ama JSON ve giden isteklerde öne geçiyor

Telegram botları için yeni bir barındırma seçeneği

Dev.to'da yayımlanan bağımsız bir kıyaslamaya göre Telegram, Temmuz 2026'da bazı yarışma katılımcılarını özel bir Serverless testine davet etmeye başladı ve pakete 6 Ekim'de Mini App barındırma eklendi. Bu hizmet, bir geliştiricinin bot handler'larını npx tgcloud push komutuyla yüklemesini, yerleşik SQLite veritabanını migration'larla kullanmasını ve bir Mini App arayüzü için HTTPS adresi edinmesini sağlıyor — bakım gereken bir işletim sistemi, ayrı bir barındırma hesabı ya da alan adı yok. Ayrıca Telegram, sunucu tarafındaki bir endpoint bir isteği almadan önce kullanıcı verilerini doğruluyor.

Runtime'ın kısıtlamaları var: sunucu tarafı kod, Telegram'ın SDK'sına göre yazılmış JavaScript olmalı; sıradan npm import'ları ve Node'un dosya sistemi API'leri orada kullanılamıyor ve dış HTTP yanıtlarının 30 MB ile sınırlı olduğu belgelenmiş. Mini App'in tarayıcı tarafı ise npm paketlerini normal şekilde kullanabiliyor.

Test nasıl kuruldu

Yazar halihazırda iki VPS işletiyordu — biri Finlandiya'da, biri Almanya'da, her biri tek vCPU ve yaklaşık 2 GB RAM'e sahip — ve üç ortamda da aynı iş yüklerini çalıştırdı. Her iki VPS de aynı Node.js ve SQLite sürümlerini, WAL modunu ve synchronous=FULL ayarını kullanıyordu. Finlandiya'nın /tmp dizininin RAM tarafından desteklendiği yönündeki erken bir hata fark edildi ve nihai veritabanı testleri kalıcı ext4 depolamada yeniden çalıştırıldı. Telegram'ın SQLite'ına yalnızca SDK üzerinden erişilebildiğinden eşitleme ayarları incelenemedi; VPS'lerde Mini App'in tam bir HTTP dağıtımı yerine paylaşılan veri modeli test edildi.

Rakamlar, ısınma örnekleri hariç tutularak üç turun medyanları: anahtar araması için 150, ekleme yöntemi başına 30, bahçe okuması için 90 ve sulama için 60 ölçüm üzerinden.

SQL işi VPS'lerden yana

VPS'ler tüm veritabanı işlemlerinde kazandı. Bir birincil anahtar araması Finlandiya'da 0,009 ms, Almanya'da 0,013 ms sürerken Telegram Serverless'ta 2 ms sürdü. 1.000 başlangıç kaydıyla bir sulamayı kabul etmek iki VPS'te 0,87 ve 0,74 ms, Telegram'da ise 22 ms tuttu — yazarın özetine göre kabaca 25–30 kat daha yavaş. 1.000 sulamalı bir bahçeyi okumak VPS'lerde yaklaşık 0,25 ms, Telegram'da 7 ms sürdü.

Satır ekleme rakamları pratik dersi taşıyor: 32 satırın ayrı ifadelerle eklenmesi Telegram'da medyan 533 ms sürdü, tek bir ifadede toplandığında ise 16 ms — sunucu değiştirmeden, yalnızca sorgu biçiminden kabaca 33 katlık bir kazanç. Toplu ekleme, çok daha düşük bir taban seviyesinden başlasa da VPS'lere de yardımcı oldu.

Hesaplama ve ağ diğer yöne gitti

CPU performansı fiilen eşitti; iki milyon tamsayı karıştırma iterasyonu üç ortamda da yaklaşık 2 ms sürdü. JSON işleme Telegram'dan yanaydı: 530 KB'lık bir belge üzerinde on parse/stringify/parse döngüsü Serverless'ta 11,1 ms, Finlandiya'da 29,8 ms ve Almanya'da 34,2 ms sürdü.

Giden fetch'ler de platformdan yanaydı. Aynı Telegram JavaScript dosyasını her ortamda 30 kez çekmek Serverless'tan 16 ms, Finlandiya'dan 54 ms ve Almanya'dan 23 ms medyan verdi; ancak yazar tek bir URL'nin bir internet hız sıralaması olmadığı konusunda uyarıyor.

Bir ölçüm uyarısı: Telegram'ın iç saati, önemsiz olmayan CPU işi için sıfır döndürdü; bu nedenle hesaplama rakamları run API'sinin bildirdiği yürütme sürelerini kullanıyor ve işlemciyi yalıtmak yerine ek yükü dahil ederek bütün blokları karşılaştırıyor.

Gözlemlenen satır sınırları

10.000 sulkamada bir bahçe okuması VPS'lerde yaklaşık 2,1 ms, Telegram'da 36 ms sürdü; 100.000'de bulut sorgusu rows_read limiti aşıldı hatasıyla başarısız oldu. Bir yoklama sınırı netleştirdi: 50.000 satırı toplamak başarılı olurken 50.001'i başarısız oldu; buna karşın 100.001 satırlık bir tabloda birincil anahtar araması hâlâ çalıştı — tablo veriyi tutabiliyor ama tam taramalar sınıra takılıyor. Yazma tarafında 10.000 satırlık tek bir ekleme başarılı oldu ve 10.001, arkada kısmi satır bırakmadan atomik olarak reddedildi; aynı fonksiyon içindeki iki 6.000 satırlık ekleme ise ikisi de başarılı oldu. Yazar, bunların tek bir erken erişim hesabında gözlemlenen sınırlar olduğunu, platform geneli yayımlanmış garantipler olmadığını vurguluyor.

1, 4 ve 8 düzeylerindeki eşzamanlı artışlar, her ortamda beklenen 65 güncelmenin tamamını korudu — bu küçük ölçekli bir denetimdir, eşzamanlı kullanıcı için bir üst sınır değil. Tüm zamanlamalar, Telegram istemcilerine mesaj teslimini ve cold start'ları hariç tutuyor.

Neden önemli

Serverless, Telegram geliştiricilerine tek bir yüklemede bot, veritabanı ve Mini App'e giden sıfır operasyonlu bir yol sunuyor ve bu da prototipler ile küçük araçlar için eşiği düşürüyor. Kıyaslamalar ödünleşimleri sayısallaştırıyor: bu iş yükü için mütevazı bir VPS'ye kabaca 25–30 kat daha yavaş bir veritabanı yolu, sıradan npm paketleri olmadan JavaScript ve Telegram'ın SDK'sıyla sınırlı bir sunucu runtime'ı ve tek bir sorgunun ne kadar veri tarayabileceğine dair pratik üst sınırlar — bunlar, her okumada tüm geçmişi yeniden hesaplamak yerine toplamları tutmak gibi tasarım değişikliklerini zorunlu kılan sınırlar. Yazarın hükmü, veritabanına yaslanan çalışan projelerde VPS'te kalmak; JSON ve fetch sonuçları ise iş SQL ağırlıklı değil hesaplama veya ağ biçimli olduğunda Serverless'ın kazanabileceğini gösteriyor. Cold start'lar ve uçtan uca teslim hâlâ ölçülmedi ve platform hâlâ erken erişimde, dolayısıyla bu rakamlar değişebilir.