Mbps is megabits per second while MB/s is megabytes per second. Using 8 bits per byte, 1 Gbps corresponds to about 125 MB/s of theoretical line rate.
Convert 100 Mbps, 1 Gbps and 10 Gbps VPS port speeds into MB/s, monthly traffic and practical concurrency limits.
Mbps is megabits per second while MB/s is megabytes per second. Using 8 bits per byte, 1 Gbps corresponds to about 125 MB/s of theoretical line rate.
Port speed is instantaneous capacity; monthly transfer is cumulative data. Unlimited traffic does not automatically mean sustained full-line-rate performance is guaranteed.
100 Mbps is theoretically 12.5 MB/s, 1 Gbps about 125 MB/s and 10 Gbps about 1.25 GB/s. TCP/IP, TLS and protocol overhead reduce real application throughput.
A 2 MB page on a 100 Mbps link produces a rough upper bound of about six full page transfers per second, but CDN/cache, compression, HTTP multiplexing and user behavior change real capacity.
If saturated continuously for 30 days, 100 Mbps is roughly 32.4 TB, 1 Gbps 324 TB and 10 Gbps 3.24 PB of theoretical transfer. Provider quotas and fair-use policies can be much lower.
On many small and medium sites CPU, PHP workers, database and cache become bottlenecks before the port. A site can be slow while a 100 Mbps link is mostly idle. Confirm saturation with network metrics.
Large file delivery, backups, video, game patches, object storage and CDN origin workloads can become bandwidth-bound much sooner.
sar -n DEV 1 10
ip -s link
ss -s
A 1 Gbps port label does not necessarily mean dedicated 1 Gbps physical bandwidth. It may be a shared uplink, VM rate limit or burst ceiling. Ask about committed bandwidth and fair-use policy.
Having a 10 Gbps port does not mean a 20 Gbps attack is automatically survivable. Scrubbing capacity, attack type, upstream filtering and L3/L4/L7 policy are separate.
| Port | Theoretical MB/s | 30 days saturated |
|---|---|---|
| 100 Mbps | 12.5 MB/s | ~32.4 TB |
| 1 Gbps | 125 MB/s | ~324 TB |
| 10 Gbps | 1250 MB/s | ~3.24 PB |
Do not buy based on one benchmark, port label or CPU brand. Repeat tests at different times, avoid destructive storage tests on production data, and verify provider resource/fair-use policies in writing.
Often yes for small/medium sites, but page size, concurrency and CDN/cache usage determine the real requirement.
Protocol overhead, VM rate limits, test server, single-stream TCP, CPU and routing can affect results.
Share your software stack, concurrency, storage/database load and target region; size the server around the real bottleneck rather than RAM/core labels alone.