UpperBee, a Canadian software-as-a-service (SaaS) company specializing in property management, has migrated its virtualized infrastructure from VMware and a SAN architecture to a platform built on Proxmox Virtual Environment (VE), Ceph, and ZFS. According to the success story published by Proxmox, the change eliminated the storage bottlenecks that had been affecting the company and quadrupled the performance of its SQL infrastructure after adopting ZFS.
UpperBee’s migration in 20 seconds
- UpperBee had a VMware infrastructure with rising support costs and hardware nearing the end of its support lifecycle.
- The old SAN was limiting performance for the development teams.
- The company moved to Proxmox VE with Ceph in a hyperconverged architecture.
- ZFS was used for SQL workloads, where UpperBee says it quadrupled performance.
- The project runs on Dell servers and 25/100 Gb Aruba networking.
The Montreal-based company builds a platform used by property managers, communities, and residents across Canada and the United States. As with other SaaS businesses, its infrastructure doesn’t just host the end product; it also underpins development, testing, software build environments, and other internal processes.
The problem was that the existing platform was starting to hold back those operations. UpperBee points to two main reasons for considering the migration. On one hand, there were the costs tied to VMware and aging hardware. On the other, the SAN storage architecture had stopped delivering the performance its development teams needed.
The chosen solution removes the SAN as a separate component for a good portion of the workloads and adopts a hyperconverged model where the servers themselves provide both compute and storage capacity.
Proxmox VE and Ceph replace the model built around a standalone SAN
UpperBee chose Proxmox VE as its new virtualization platform. The company valued the ability to manage virtualization, clustering, high availability, and software-defined storage from a single open-source platform.
One of the main technical decisions was to use Ceph as distributed storage for its general-purpose virtual machines.
In a traditional SAN-based architecture, virtualization servers consume storage provided by external infrastructure. The hyperconverged approach UpperBee chose spreads storage across the nodes themselves and uses Ceph to manage and replicate that data.
That doesn’t mean Ceph automatically eliminates every performance problem or fits every workload. Its behavior depends on the number and characteristics of the nodes, the storage devices, the network, the configuration, and the redundancy levels chosen.
UpperBee specifically sized its processors and memory with Ceph in mind and paired the servers with a high-capacity network.
The infrastructure uses Dell servers and 25/100 Gb Aruba switches configured with Multi-Chassis Link Aggregation (MLAG). On top of that, three types of traffic were separated onto dedicated interfaces: Corosync for latency-sensitive cluster communications, Ceph for storage replication, and the front-end traffic used by virtual machines and users.
That separation matters in a hyperconverged infrastructure because storage, virtual machines, and cluster communications physically share part of the same platform. An undersized or poorly configured network could simply move the old storage bottleneck to another point in the infrastructure.
ZFS for SQL, Ceph for virtual machines
UpperBee also didn’t use Ceph indiscriminately for every workload.
The new architecture differentiates storage based on the job at hand. Ceph provides distributed storage for general virtual machines, while ZFS is used as the storage layer for the SQL infrastructure.
It’s precisely in that last area where one of the project’s most striking figures shows up.
Cédric Deschamps, CTO and co-founder of UpperBee, says the switch to ZFS delivered a fourfold performance increase.
That figure should be understood as the result UpperBee reported for its own infrastructure, not as an improvement that can be automatically extrapolated to any migration from a SAN to ZFS.
Database performance depends on many factors: the previous storage, the disks used, available memory, caching, ZFS configuration, write patterns, synchronization, and the characteristics of the database itself, among others.
What the case does show is an interesting architectural decision: using different storage technologies within the same Proxmox environment instead of trying to handle every workload with a single layer.
Proxmox VE offers native support for both Ceph and ZFS. In UpperBee’s case, that combination provides distributed storage for some workloads and local ZFS storage for those where a different behavior was needed.
The company also credits the migration with eliminating the bottlenecks from its old SAN that had been affecting development workflows.
UpperBee’s own team carried out the migration from VMware
The rollout involved Images et Technologie, a Canadian integrator and authorized Proxmox partner based in Montreal.
Its work included designing the architecture, sourcing the hardware, fully preconfiguring the cluster, and providing technical guidance.
The integrator then handed over the platform, configured and validated. From that point on, UpperBee’s own team carried out the migration of workloads from VMware to Proxmox VE.
This detail matters because one of the usual concerns when evaluating an alternative to VMware isn’t just hypervisor-to-hypervisor equivalence. Operational procedures, management tools, the team’s know-how, and the ability to manage the new infrastructure once the migration project wraps up also come into play.
UpperBee was specifically looking to regain some of that internal control.
The company has also found a new use for its old servers. Instead of retiring them entirely, it can put them to work on tasks that don’t need the primary infrastructure, such as build servers, staging environments, or backup targets.
Proxmox also points to a lower total cost of ownership (TCO) and reduced vendor lock-in compared with the previous environment. No financial figures have been published, though, that would allow the savings to be calculated or the cost of both platforms to be compared directly.
That makes the case more useful from an architectural standpoint than as a universal economic comparison between VMware and Proxmox.
UpperBee has moved from an infrastructure where virtualization and the SAN were separate components to one where Proxmox VE, Ceph, and ZFS let it combine several storage models within a single management platform.
And the outcome isn’t simply swapping one hypervisor for another. The company redesigned its servers, storage, and networking at the same time, with links of up to 100 Gb and separate networks for Ceph and Corosync.
It’s an important distinction for any similar project: swapping VMware for Proxmox can be part of a migration, but getting performance gains like the ones UpperBee reported requires reviewing the entire architecture underneath it.
Frequently Asked Questions
Why did UpperBee migrate from VMware to Proxmox?
The company points to rising support costs, aging hardware, and performance issues with its SAN architecture. It also wanted to reduce dependence on proprietary vendors and gain more control over its infrastructure.
What does UpperBee use Ceph for?
Ceph provides distributed storage for the general virtual machine workloads within the new hyperconverged architecture.
Where does UpperBee use ZFS?
UpperBee uses ZFS as the storage layer for its SQL infrastructure. Its CTO says that setup delivered a fourfold performance increase compared with the previous environment.
What network does the new Proxmox cluster use?
The infrastructure uses 25/100 Gb Aruba switches with MLAG. Separate interfaces were dedicated to Corosync traffic, Ceph replication, and communications for virtual machines and users.
Source: Proxmox