Low cost VPS server: expand storage or upgrade?
Expand storage first if your netcup VPS only needs more data capacity and your application can use a separate disk; the worked example below costs less than the larger server contract, without claiming faster performance.
The exact decision
This is a calculation scenario, not a measured workload: match the larger plan's advertised 256 GB using the smaller plan's 128 GB plus an additional disk. The target comes from the plan specifications, not a claim about how much space your website needs. [A] [B]
Both plan quotes use automatic European location selection, dual-stack networking, a 12-month minimum term and billing period, and 19% VAT. Storage is billed in 30-day periods. The example buys the full server term and exactly 12 storage periods = 360 days; it does not equate those days with a calendar year. No renewal is included. [A] [B] [D]
Backup, software licences and operator time are outside this storage decision. No migration or restore test was run. An existing customer's upgrade quote and unused-fee credit must be checked separately. [E]
Published inputs
Calculation: buy only the missing capacity
Subtract the storage already included before pricing an add-on. In this case, the missing capacity is 256 − 128 = 128 GB. Charging for the entire target again would double the additional disk in this scenario. The added disk and the existing disk meet the advertised capacity target together; they do not become a single enlarged system disk. [A] [B] [D]
Additional disk per storage period = round(128 × €0.012 × 1.19, 2) = €1.83.
Selected storage duration = 12 × 30 = 360 days.
Storage charge for that duration = 12 × €1.83 = €21.96. [C] [D]
Round the charge for each billing period before multiplying by the number of periods. Keep the server's contractual charge separate: buying a shorter stretch of extra storage does not shorten the server contract. This avoids treating the advertised monthly equivalent as permission to leave the base plan early.
Smaller server term = 12 × €5.91 = €70.92.
Smaller server term plus selected storage duration = €70.92 + €21.96 = €92.88.
Larger server term = 12 × €10.36 = €124.32.
Difference between these specified purchases = €124.32 − €92.88 = €31.44. [A] [B]
Inference: expansion has the lower quoted purchase cost for this storage-only scenario. The larger plan also buys more compute and memory, so the difference is not evidence that the larger plan is poor value for a workload that needs those resources. Neither price proves usable filesystem capacity or application performance.
Unit conversion you can reproduce
Using the provider's own convention: 256 ÷ 1024 = 0.25 TB; the extra 128 ÷ 1024 = 0.125 TB. [C]
Enter the additional capacity, not the combined target, into the storage order. Keep the GB value in your saved comparison so a different unit label cannot quietly change the purchase. Keep the storage duration alongside it: extending storage to the end of the calendar-year server term requires a further charge that this deliberately shorter example does not include.
Downloadable decision table
The amounts below are calculated from published quotes for the stated purchases, not actual invoices. The empty migration amount is intentional: neither a timetable nor a remaining-contract bill has been measured.
| Route to the capacity target | Calculation | EUR, VAT included | What must still be checked |
|---|---|---|---|
| Small plan + separate disk | (12 × 5.91) + (12 × 1.83) | 92.88 | Full server term; extra disk for 360 days only. Application can place data on that disk. |
| Larger plan purchased directly | 12 × 10.36 | 124.32 | Full server term. Additional compute and memory are part of the purchase. |
| Existing-server upgrade | New contract charge − confirmed unused-fee credit | Use the account's upgrade quote and credit; a public new-order price is not your upgrade invoice. | |
| New server + migration | New contract + old unpaid commitments + measured migration costs | Fill from actual dates, invoices and work records before comparing the transition cost. |
Inputs: A, B, C, D; upgrade-credit rule: E. Blank means unknown, not free.
Download comparison & calculations (HTML)Before changing an existing server
- Open the server in the Customer Control Panel. Check Local Block Storage for the actual storage order and Administration for available upgrades. Record the amount and term from each offer before committing. [D] [E]
- An upgrade begins a new contract and billing period; unused base fees are credited. Use the actual credit in the table. A new server plus migration is a different transaction and does not inherit that upgrade credit. [E]
- Additional storage is a separate virtual disk. Confirm how you will mount it and move the intended data. The vendor does not offer direct disk shrinking; reducing capacity requires another disk and a data transfer. [C] [D]
- If the problem is slow queries, memory pressure or recovery rather than capacity, this price calculation cannot settle it. Collect the relevant workload or recovery measurements before choosing hardware on that basis.
Evidence and number sources
All pages checked September 21, 2026. This is the verification date, not a vendor offer-expiry date. Published prices can change. Product names contain model identifiers, not benchmark results.
- A — smaller plan: VPS 500 G12 configuration. Capacity, CPU, RAM, monthly equivalent, setup fee, European location choice, dual stack, term, billing period and VAT. Default German-tax quote used here.
- B — larger plan: VPS 1000 G12 configuration. The same fields for the larger plan. The worked term charges are arithmetic from these displayed monthly equivalents.
- C — storage rate and units: Local Block Storage pricing. Pre-VAT unit rate, rounding, TB-to-GB convention and shrinking restriction. The tax multiplier comes from A/B. All added capacities, conversions and price differences above are shown calculations.
- D — billing and disk type: Local Block Storage documentation. Separate virtual disk, billing period and order workflow. The selected number of storage periods is an explicitly chosen scenario, not measured usage.
- E — existing customer terms: Product Upgrade documentation. Upgrade availability, fresh term, unused-fee credit and restart requirement. No measured restart duration or migration price is asserted.
What people who hit the limit say in their own words
Reproduced verbatim and unedited, each with its discussion title, link and date. These are experience reports from people who ran into a storage limit, not official provider wording and not this page's conclusion. Where a quote and the evidence above disagree, the linked official page states the published rule and the quote stays as one person's experience.
How these are counted: one sample is one discussion thread, not one person. Several people replying inside the same thread count once. The four quotes come from three threads: quotes 1 and 2 come from one thread about a provider's hosting plans, quote 3 from a thread about replacing block storage, quote 4 from a thread about a spot pricing page.
Reported in more than one thread: one thing — adding capacity is not simply a matter of paying more. Quote 1 and quote 2 (thread one) report that allocated-but-unused space still counts against the quota, quote 3 (thread two) lists the constraints that came with block volumes: billed for allocation, a resize window of once every 6–24 hours, and no shrinking back, quote 4 (thread three) reports a server that could not be reprovisioned after being given the wrong disk size.
Not found: no first-person quote was found that compares, on the same machine, the cost of adding block storage against the cost of moving to a larger plan. That is the exact comparison this page makes, and it is absent from the discussions checked. Two of the quotes below are about reseller hosting accounts rather than VPS plans; they are included for the capacity accounting, and the product difference is stated.
1 · Allocated but unused space still counts · capacity
Heads up: with Reseller accounts Oversell – Disabled. So actual disk space is shorter comparing to competitors. I have not tried to ask enabling it dou. I would try, if there was no prior reports on rude support responses.
Where this gets stuck: the quota you are billed for and the data you actually hold are not the same number. Way around it: measure allocated space separately from used space before deciding how much to add.
2 · You lose the space just by allocating it · capacity
Oversell – Disabled and they won't enable it on request. Responding rude. "Go to website". "Not listed means not allowed" and so on. So yes you will loose actuall disk space just by allocating, but never using it. They should warn about they have Oversell – Disabled.
Where this gets stuck: the rule is a plan setting, not a usage behaviour, so it cannot be fixed by tidying up files. Way around it: ask whether allocation or usage is counted before you size the add-on, and get the answer in writing.
3 · Billed for allocation, and you cannot resize freely · capacity
Why EBS didn't work: - EBS costs for allocation - EBS is slow at restores from snapshot (faster to spin up a database from a Postgres backup stored in S3 than from an EBS snapshot in S3) - EBS only lets you attach 24 volumes per instance - EBS only lets you resize once every 6–24 hours, you can't shrink or adjust continuously
Where this gets stuck: the add-on is billed on what you reserve and can only be changed rarely, so oversizing is expensive and undersizing is slow to fix. Way around it: size the add-on from measured growth and check the resize interval before you commit, because a wrong guess cannot be corrected the same day.
4 · The wrong disk size could not be fixed later · capacity
When I worked at rackspace in 2016/2017 we couldn't even internally get a critical Openstack server reprovisioned after it was accidentally given 4GB of disk instead of 4GB of ram and would break when it ran out of disk space. Nobody knew how to reprovision it and the company's internal documentation wasn't accurate so the server malingered around with its unnecessarily large 64GB memory pool.
Where this gets stuck: capacity chosen at order time can outlive the person who chose it, and the fix may be a rebuild rather than a resize. Way around it: check whether your provider can resize in place before ordering small, and assume a rebuild is the fallback.