Telegram Serverless trails VPSs on SQLite, wins on JSON and outbound fetches

A new hosting option for Telegram bots

Telegram began inviting some contest participants into a private Serverless test in July 2026, and Mini App hosting was added to the package on October 6, according to an independent benchmark published on dev.to. The offering lets a developer upload bot handlers via the npx tgcloud push command, use a built-in SQLite database with migrations, and receive an HTTPS address for a Mini App's interface — no operating system to maintain and no separate hosting account or domain. Telegram also verifies user data before a server-side endpoint receives a request.

The runtime has constraints: server-side code must be JavaScript written against Telegram's SDK, ordinary npm imports and Node's filesystem APIs are unavailable there, and external HTTP responses are documented as capped at 30 MB. The browser side of a Mini App can use npm packages normally.

How the test was built

The author already operated two VPSs — one in Finland, one in Germany, each with a single vCPU and about 2 GB of RAM — and ran identical workloads on all three environments. Both VPSs used the same Node.js and SQLite versions with WAL mode and synchronous=FULL. An early mistake, Finland's /tmp being backed by RAM, was caught and the final database tests were rerun on persistent ext4 storage. Telegram's SQLite is reachable only through its SDK, so its synchronization settings could not be inspected; on the VPSs the shared data model was tested rather than a full HTTP deployment of the Mini App.

Figures are medians over three rounds with warm-up samples excluded, based on 150 measurements for the key lookup, 30 per insertion method, 90 for a garden read and 60 for a watering.

SQL work favored the VPSs

The VPSs won every database operation. A primary-key lookup took 0.009 ms in Finland and 0.013 ms in Germany versus 2 ms on Telegram Serverless. Accepting a watering with 1,000 starting records cost 0.87 and 0.74 ms on the two VPSs against 22 ms on Telegram — roughly 25–30 times slower, in the author's summary. Reading a garden of 1,000 waterings took about 0.25 ms on the VPSs and 7 ms on Telegram.

The insert rows carry the practical lesson: 32 rows inserted as separate statements took a median of 533 ms on Telegram, but 16 ms when batched into one statement — a roughly 33-fold gain from query shape alone, without changing hosts. Batching helped the VPSs too, from a far lower baseline.

Compute and network went the other way

CPU performance was effectively tied, with two million integer-mixing iterations taking about 2 ms in all three environments. JSON processing favored Telegram: ten parse/stringify/parse cycles over a 530 KB document took 11.1 ms on Serverless, 29.8 ms in Finland and 34.2 ms in Germany.

Outbound fetches also favored the platform. Pulling the same Telegram JavaScript file 30 times per environment gave medians of 16 ms from Serverless, 54 ms from Finland and 23 ms from Germany, though the author cautions that one URL is not an internet speed ranking.

One measurement caveat: Telegram's internal clock returned zero for nontrivial CPU work, so compute figures use execution time reported by the run API and compare whole blocks, overhead included, rather than isolating the processor.

Observed row limits

At 10,000 waterings, a garden read took about 2.1 ms on the VPSs and 36 ms on Telegram; at 100,000 the cloud query failed with a rows_read limit exceeded error. A probe pinned the boundary: summing 50,000 rows succeeded while summing 50,001 failed, yet a primary-key lookup in a table of 100,001 rows still worked — the table can hold the data, but full scans hit the cap. On writes, a single insert of 10,000 rows succeeded and 10,001 was rejected atomically, with no partial rows left behind, while two 6,000-row inserts inside the same function both succeeded. The author stresses these are limits observed on one early-access account, not published platform-wide guarantees.

Concurrent increments at levels of 1, 4 and 8 preserved all 65 expected updates in every environment — a small-scale check, not a ceiling on concurrent users. All timings exclude message delivery to Telegram clients and cold starts.

Why it matters

Serverless gives Telegram developers a zero-operations path to a bot, a database and a Mini App in a single upload, which lowers the barrier for prototypes and small tools. The benchmarks quantify the trade-offs: a database path roughly 25–30 times slower than a modest VPS for this workload, a server runtime restricted to JavaScript and Telegram's SDK without ordinary npm packages, and practical caps on how much data one query can scan — limits that force design changes such as keeping running totals instead of recalculating full history on every read. The author's verdict is to stay on a VPS for working projects that lean on a database, while the JSON and fetch results suggest Serverless can win where the work is compute- or network-shaped rather than SQL-heavy. Cold starts and end-to-end delivery remain unmeasured, and the platform is still in early access, so these numbers may move.