If you have had a very old Ubuntu/Linux server that you had recently noted does not receive security updates (without paid subscription), you may have certainly looked in to the pros/cons of creating an entirely new server of a newer Ubuntu, vs Ubuntu upgrade process. There may be more advantages than you think, to start an entirely new droplet:
New region means more potential upgrades in the future
If you check the “Upsize Droplet” option within the Digitalocean dashboard on one of your older droplets in an older region, you may see something like this:
As you can see, there are a variety of types (shown in grey above) that are not available for future potential upgrades if a service gets much more popular and must scale. One could end up having to pay more for future upgrades, since these $7/month or $8/month options with higher cpu capacity are not available in the entire region.
Actual benchmark performance
The cpus on an older datacenter will be running older CPUs, while a newer one will be somewhat faster – at the same price. For example, run “cat /proc/cpuinfo” on a budget $6/month droplet. On SFO3:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : DO-Regular
stepping : 1
microcode : 0x1
cpu MHz : 2494.140
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt arat vnmi md_clear
vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid shadow_vmcs pml
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data bhi
bogomips : 4988.28
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
And on SFO2:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : DO-Regular
stepping : 1
microcode : 0x1
cpu MHz : 2294.608
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt arat md_clear
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data
bogomips : 4589.21
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
Now Digitalocean is not showing what precise CPU is running the virtual server, but you can see it is 200mhz faster. The flags including “vmx flags” here are due to the differing versions – Ubuntu 18.04 and the newer linux in Ubuntu 24.04, not hardware differences. A 6 year old Ubuntu may have significantly slower software for some tasks.
On SFO2 the following was set, 800-1000 events per second on sysbench.
sysbench --test=cpu run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.20 (using system LuaJIT 2.1.1700206165)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 833.00
General statistics:
total time: 10.0010s
total number of events: 8333
Latency (ms):
min: 0.97
avg: 1.20
max: 3.27
95th percentile: 1.39
sum: 9986.27
Threads fairness:
events (avg/stddev): 8333.0000/0.00
execution time (avg/stddev): 9.9863/0.00
On SFO3, this is significantly faster for me, also on a new droplet with the same Ubuntu 24.04: Around 1700-2100 CPU events per second! Whether this just happens to be the load on a much less overloaded server center, or new cpu, this highlights the performance boost at the same price point on the newer region:
sysbench --test=cpu run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.20 (using system LuaJIT 2.1.1700206165)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1745.96
General statistics:
total time: 10.0001s
total number of events: 17464
Latency (ms):
min: 0.46
avg: 0.57
max: 23.40
95th percentile: 0.83
sum: 9977.53
Threads fairness:
events (avg/stddev): 17464.0000/0.00
execution time (avg/stddev): 9.9775/0.00
What about AWS?
As others have noted, Amazon AWS is more complicated in their pricing and availability. They have a wider variety of features than DigitalOcean, but more complex pricing and availability. A recent article from Plerion finds that some common AWS setups can be hijacked by some cleverly chosen s3 buckets and items.