How far do Vercel, Neon, Supabase, Firebase and a single VPS scale?

The scaling ladder

1. Static pages and a CDN: the cheapest rung and the one that carries the most load.
2. Caching: serve frequently read data without hitting the database.
3. Query and index tuning: most slowness comes from one bad query.
4. Connection pooling: protects the database's connection limit under many concurrent requests.
5. Vertical scaling: give the database or server more CPU and memory.
6. Read replicas: spread the read load across other servers.
7. Splitting services and sharding: the rare and most expensive rung.

Most projects never go past the first four rungs. That is why building a complex architecture early is usually unnecessary.

Vercel and serverless functions

Static pages and a CDN carry very high traffic easily. Functions run in parallel as load grows; the real bottleneck is usually the database they talk to. Because each function instance can open its own connection, a few hundred concurrent requests can fill a Postgres's connection limit.

Neon and Postgres

Neon provides connection pooling with PgBouncer; a pooled connection string adds -pooler to the hostname, and the pooler turns many client connections into a smaller number of real Postgres connections. Because the pooler runs in transaction mode, features that depend on session state, such as SET, LISTEN and NOTIFY, or session-level locks, won't behave as you expect. A common split is the pooled string for application traffic and the direct string for migrations.

On scaling, Neon's compute grows automatically within your plan (as of October 2026, up to 2 CU on the free plan and higher on paid plans). A single Postgres with vertical scaling, indexes and read replicas is enough for most applications.

Supabase

Supabase runs standard Postgres underneath, so the scaling rules for Postgres apply here too: indexes, pooling, a larger instance and read replicas. You can start on a small instance and grow. Remember that on the free plan, inactive projects get paused.

Firebase and Firestore

Firestore scales horizontally and automatically, so it absorbs traffic growth without you managing servers. The price is the data model and the cost: the number of reads and writes sets the bill, and the sustained write rate to a single document is limited (about one per second). You have to design your queries and document structure around that from the start.

A single VPS

A single VPS goes surprisingly far for low and medium traffic, because the bottleneck is usually the database and disk before the CPU. Its limit is vertical scaling and it is a single point of failure: if the server goes down, everything does. You need backups, monitoring and a restore plan.

Is it time to move to something else?

• You see database connection errors or timeouts.
• Cold-start latency is bothering users.
• The bill grows out of proportion to traffic.
• You've hit a platform's hard limit (storage, execution time, concurrency).
• Your requirements have outgrown what the platform offers (private networking, compliance, custom infrastructure).

If none of these show up, don't move. Measure first: the real problem is often just an index or a cache.