A comparison published by Naranjatec presents its Private Cloud as a more affordable alternative to Stackscale, using CPU, RAM, and storage cost as the reference. That approach gives a sense of what certain resources cost, but it isn’t enough to determine which platform is actually cheaper when the architecture, compute model, storage, high availability, and associated services aren’t necessarily equivalent. On top of that, in a market shaped by hardware costs — especially components like memory — turning a snapshot of prices into a permanent conclusion can make any comparison age quickly.
The Stackscale-Naranjatec comparison in 30 seconds
- Naranjatec compares virtual resources against infrastructure that Stackscale mainly sells on dedicated physical nodes.
- A vCore or vCPU doesn’t necessarily equal a physical core, so comparing their unit prices can lead to the wrong conclusions.
- Local NVMe storage and centralized enterprise network storage solve different needs.
- High availability, snapshots, replication, disaster recovery, networking, and support are also part of the cost.
- To find out which provider is really cheaper, you’d need to ask both for the exact same architecture and compare total cost.
The question here isn’t whether the prices a provider publishes are good or bad. Naranjatec can offer an economically attractive proposition for certain projects. The problem shows up when a unit price is used to infer the cost of an entire infrastructure.
The documentation used as the starting point for this analysis raises exactly that distinction: a rigorous comparison should normalize architecture, storage, availability, networking, support, and contract terms before deciding which alternative is actually cheaper.
In enterprise infrastructure, two offers with the same nominal amount of CPU, RAM, and terabytes can be delivering very different services.
A vCPU and a Physical Core Aren’t the Same Unit
The first thing that should be checked in any comparison like this is the CPU.
Naranjatec expresses part of its offering in vCores. Stackscale structures its Private Cloud around dedicated physical nodes that include a set number of processors, cores, memory, and local storage. It currently offers generations based on both Intel Xeon and AMD EPYC.
Later converting those servers into a theoretical price per core to weigh it against the price of a vCPU introduces a significant simplification.
A physical core is a resource on the processor installed in the server.
A vCPU or vCore is an abstraction the hypervisor presents to a virtual machine. The effective capacity it represents depends on the physical processor, its generation and clock speed, the hypervisor’s scheduling policy, the number of simultaneous workloads, and the resource allocation policy.
This doesn’t mean a vCPU necessarily performs worse.
It means you can’t establish a universal equivalence of one vCPU equals one physical core.
Two platforms might advertise 100, 200, or 500 vCPUs and deliver very different real-world capacity. Comparing them correctly requires knowing what processors sit underneath, how many physical resources are available, and what allocation policy each platform applies.
For the same reason, independently adding up CPU and RAM to estimate Stackscale’s price doesn’t necessarily reflect its commercial model either.
Stackscale sells Private Cloud on dedicated servers where CPU and memory are part of the same node.
The customer isn’t necessarily buying an abstract pool of vCPUs and gigabytes of memory, but physical capacity that can later be virtualized through Proxmox VE or VMware.
Storage Is Where the Comparison Gets Most Complicated
Capacity is probably the most misleading metric when comparing storage systems.
Two infrastructures can both offer 10 TB while solving completely different problems.
A server with local NVMe drives can deliver very low latency and a high number of input/output operations per second (IOPS). For databases, caches, intensive processing, and many other workloads, it can be an excellent choice.
It’s also usually an efficient way to get a lot of performance per euro spent.
The problem shows up when it’s compared directly against centralized enterprise storage as if only the price per gigabyte changed.
Stackscale combines local disks on its nodes with an independent centralized network storage platform, with different service tiers. Its public documentation specifies storage built on NetApp systems, different latency and IOPS targets, snapshots, and geo-replication for several of its tiers.
It also has storage with synchronous replication between two Madrid data centers, aimed at architectures that require recovery point and recovery time objectives (RPO and RTO) of zero under the service terms.
So simply talking about “storage” hides an important part of what’s actually being compared.
| Feature | Local NVMe | Network enterprise storage |
|---|---|---|
| Location | Inside the server | Independent storage platform |
| Latency | Potentially very low | Depends on tier and network |
| IOPS | Generally high | Depend on the contracted service |
| Node dependency | High without an extra protection layer | Compute and data can be decoupled |
| Access from multiple nodes | Needs additional architecture | Can be designed as shared storage |
| VM mobility | Depends on replication or disk migration | Simpler with shared storage |
| Snapshots | Depend on the solution | Can be part of the platform |
| Geo-replication | Needs additional mechanisms | Can be built into the service |
| Typical use | Local performance and specific workloads | Virtualization, HA, continuity, and persistent data |
Neither approach is universally better.
What matters is knowing what the application actually needs.
If a company needs fast NVMe capacity inside a server and has its own data-protection strategy, local storage can offer an excellent cost-to-performance ratio.
If it needs to move machines between hosts, decouple compute and data, keep snapshots, or replicate information across locations, the problem is different.
And so will its cost.
What Happens When a Node Fails?
This scenario makes the difference easier to see.
A virtual machine can sit on one server and store its disks only on that same machine’s local NVMe drives.
If the server suffers a physical failure, recovering the machine on another node will depend on whatever additional mechanisms have been put in place: replication, distributed storage, backup, or another technology.
In a cluster that uses shared storage accessible from different servers, another node can keep accessing the data. With a properly designed high-availability platform, the virtual machine can be started on another host.
None of this means Naranjatec lacks mechanisms to deal with a server failure. The absence of public detail about a specific feature doesn’t prove that feature doesn’t exist.
The right question for any provider would be:
What happens to my machines and my data when one of the servers fails completely?
And then: what RPO, RTO, and SLA are you committing to?
Those answers say far more about a platform than the price of 1 GB does.
KVM and Proxmox Aren’t Opposing Concepts Either
There’s another comparison that deserves a technical clarification.
Naranjatec states it uses KVM together with Virtualizor. Stackscale offers Proxmox VE as one of its main virtualization platforms.
But Proxmox VE also uses KVM to run virtual machines.
The difference lies in the management layers and in how the infrastructure is subsequently built.
Proxmox VE integrates KVM virtualization and LXC containers along with cluster management, high availability, storage, networking, migration, and centralized administration. It can also be paired with Proxmox Backup Server to build a dedicated protection platform.
Stackscale offers Proxmox on its dedicated nodes and, depending on the design contracted, combines it with enterprise storage and high-capacity private networks.
Virtualizor also serves to manage virtualized environments, and it wouldn’t be right to conclude, based on the platform’s name alone, that one alternative is superior.
Again, what should be compared is the resulting architecture. As covered in our look at Proxmox vs. VMware and Hyper-V, the platform layer around the hypervisor is what actually decides the outcome.
How many nodes are there? Is there a cluster? How is quorum managed? Where do the machines’ disks live? Is there HA? What happens if a host is lost? How are backups done?
Answering those questions lets you compare platforms.
Comparing only the hypervisor doesn’t.
High Availability: Capacity You Pay for But Hope Not to Use
There’s also a cost that’s especially hard to represent in a per-vCPU table: reserve capacity.
Say a company needs three servers to handle its entire workload.
It can contract three machines and run them at close to full capacity.
But if it needs its applications to keep running when one fails, the architecture will need enough spare capacity on the remaining nodes to absorb the affected machines.
That margin has a cost even though it goes unused most of the time.
Stackscale documents Private Cloud architectures with dedicated nodes, redundancy, and high-availability capabilities. Its platform also includes spare nodes and geo-replication options.
The point applies to any provider.
Having three servers doesn’t automatically mean having high availability.
You also need storage, networking, quorum, spare capacity, failure-detection mechanisms, and procedures to recover the workloads.
That’s why a VM using eight vCPUs can have a very different cost depending on what’s expected to happen when its physical server disappears.
Networking Is Also Part of the Infrastructure
Networking usually gets pushed to a footnote in many cloud comparisons.
On a distributed platform, it’s a central piece.
Stackscale documents nodes with high-capacity links and different generations reaching several dozen gigabits per second, plus redundant infrastructure for storage, private interconnect, and internet egress.
That doesn’t mean a bigger interface number automatically makes a provider better.
A simple web application will probably never come close to those limits.
But the picture changes when storage access, virtual machine migrations, replication, backups, or large volumes of traffic between nodes are running over that network.
In those architectures, the internal network can determine the overall performance.
A proper comparison should therefore include capacity, redundancy, topology, included traffic, and connectivity between the platform’s different elements.
One Location and Several Locations Solve Different Problems
Something similar happens with data centers.
Infrastructure hosted in a single data center can be perfectly valid for many applications.
When requirements for disaster recovery, geo-replication, or continuity in the event of a total site loss appear, having infrastructure in other locations allows for different designs.
Stackscale runs Private Cloud in Madrid and Amsterdam and offers replication and disaster-recovery solutions backed by its storage and network infrastructure. Its synchronous storage service uses two physically separate Madrid data centers.
Naranjatec runs its cloud infrastructure in Amsterdam.
That doesn’t automatically make one platform better than the other.
A company that only needs to host an application in the Netherlands may get no benefit from having more locations.
For another that needs to separate production and disaster recovery across data centers, that option can carry real economic and operational value.
Snapshot, Backup, Replica, and Disaster Recovery Aren’t Synonyms
Another common mistake in infrastructure comparisons is lumping every protection technology under the word “backup.”
A snapshot lets you recover an earlier storage state.
A backup creates a copy meant for recovery under specific retention policies.
A replica keeps another copy of the data on a different system.
Synchronous replication aims to keep systems updated with the same information at the same time.
And disaster recovery defines how full applications and services are restored after an incident.
Stackscale documents snapshots and geo-replication across several tiers of its network storage, plus dedicated backup and DR services.
This matters because the same 10 TB of capacity can come with completely different levels of protection.
Asking only how much it costs to store those 10 TB leaves out exactly the cost of protecting them.
What a Truly Equivalent Comparison Should Include
The original table can be useful as a commercial approximation, but it isn’t enough to decide which infrastructure offers a lower cost for running the same applications.
A more complete comparison would look something like this:
| Aspect | What should be normalized |
|---|---|
| CPU | Model, generation, physical cores, threads, and vCPU allocation |
| RAM | Physical capacity and actually available capacity |
| Virtualization | Hypervisor, management, clustering, and licensing |
| Nodes | Number of servers and capacity of each one |
| Redundancy | N, N+1, or another architecture |
| Storage | Local, shared, or distributed |
| Storage performance | IOPS, throughput, and latency |
| HA | Behavior when a node fails completely |
| Snapshots | Frequency and retention |
| Backup | Technology, capacity, retention, and location |
| Replication | Synchronous or asynchronous, and distance between copies |
| DR | Procedure and alternate location |
| RPO/RTO | Maximum data loss and recovery time |
| Networking | Interfaces, redundancy, and internal capacity |
| Internet | Bandwidth and included traffic |
| SLA | Which components it covers and at what availability |
| Support | Hours, scope, and responsibilities |
| Contract | Term, onboarding, and minimum commitments |
| Scalability | Cost and procedure to grow |
At that point, it would make sense to request two quotes.
For example, a company could ask for a platform with a given amount of usable CPU and 1 TiB of RAM, 10 TiB of storage, tolerance for a single node failure, shared storage, specific IOPS and latency levels, snapshots, backup with a defined retention period, geo-replication, a defined RPO and RTO, redundant connectivity, and 24/7 support.
Both providers would have to answer the same problem.
The final price of those two proposals would be a far more useful comparison than dividing the cost of one vCPU by the cost of another.
Naranjatec Can Still Be Cheaper — and the Comparison Can Still Be Insufficient
There’s an important distinction here.
Questioning the methodology used to compare both platforms doesn’t mean claiming Naranjatec is necessarily more expensive.
The opposite could well be true.
For a company that prioritizes price, needs dedicated hardware with virtualization and high-performance local storage, and doesn’t require certain levels of centralized storage, replication, HA, or disaster recovery, its offer can be economically very competitive.
The mistake would be automatically extrapolating that result to any project.
Stackscale proposes an enterprise infrastructure model built on dedicated physical nodes that can be combined with Proxmox VE, centralized storage, different service tiers, high-capacity networks, high availability, replication, and multiple locations.
All of that costs money.
But removing it from the comparison doesn’t make its cost disappear: it means different services are being compared.
This nuance matters even more at a time when hardware costs can shift significantly. Memory, storage, processors, and other components directly affect the cost of building dedicated infrastructure, so a price snapshot taken at a given moment can quickly become outdated.
For a CIO or infrastructure lead, the useful question shouldn’t be who sells a vCPU cheaper.
It should be how much it costs to keep applications running with the performance, availability, data protection, and recovery capability the business actually needs.
And answering that means looking well below the virtual machine.
Cheaper per vCPU doesn’t necessarily mean cheaper for running the same infrastructure.
Frequently Asked Questions
Can you directly compare the price per vCPU of two cloud providers?
Only when the underlying conditions are sufficiently equivalent. Processors, resource allocation, overcommit, physical architecture, and service level can all make two vCPUs represent different capacities.
Is local NVMe storage better than network storage?
It depends on the application. Local NVMe can deliver an excellent performance-to-cost ratio, while centralized storage is especially useful when you need node-independent data, shared storage, HA, snapshots, or replication.
Does Proxmox VE use KVM?
Yes. Proxmox VE uses KVM to virtualize machines and adds a management platform that includes clustering, HA, networking, storage, and other functions.
How should the price of two private clouds be compared?
By requesting an equivalent architecture from both providers and defining CPU, RAM, storage, redundancy, HA, backup, replication, networking, SLA, RPO, RTO, support, and contract length before comparing total cost.
Sources:
- Naranjatec, comparison Cheaper alternative to Stackscale and public Private Cloud documentation.
- Stackscale, Private Cloud and dedicated nodes documentation.
- Stackscale, network storage and synchronous geo-replication documentation.
- Stackscale, disaster recovery and backup solutions.
- Proxmox, official Proxmox Virtual Environment documentation.
Note on pricing and terms: The features, rates, and commercial terms of cloud services can change, especially during periods of shifting component costs such as RAM, storage, and processors. This article mainly analyzes architectural and service differences and should not be read as a commercial quote. For an up-to-date economic comparison, it’s advisable to request proposals from providers based on the same architecture, capacity, availability level, support, and contract terms.
