Three quotes arrive for backup storage and each one prices something slightly different. One states raw capacity, another states capacity after a data reduction assumption, and the third includes three years of support where the others include one. Ranking them on the bottom line produces an answer, but not a reliable one, because the numbers being ranked do not describe the same thing.
The usual remedy is a spreadsheet with a column per vendor. That helps only if the rows are defined first and each vendor answers the same rows rather than the ones their proposal was built around. Otherwise the spreadsheet inherits each vendor's framing, and the comparison presents differences rather than measuring them.
The output of the exercise is not a winner. It is a normalized set of figures with the assumptions written next to them, which is what survives being questioned by a finance team, an auditor or the person who inherits the platform.
Define the unit being priced
Every comparison needs one unit that all quotes convert into. The most durable choice is cost per usable terabyte per year, where usable means writable after the protection scheme is applied and before any data reduction is assumed. That definition is deliberately conservative, since it is the only one that does not depend on a claim about the data.
Getting there requires knowing what each vendor means by capacity. Raw is the sum of the drives. Usable is what remains after erasure coding or replication, formatting overhead, and whatever the system reserves for rebuild and metadata. Effective is usable multiplied by an assumed reduction ratio. Those numbers can differ by a large factor, and quotes move between them without saying so, which is why establishing what usable capacity actually means comes before any pricing question.
Once the unit is fixed, every quote converts into it. Where a vendor declines to state usable capacity without a discovery exercise, that is itself a finding, and the model can hold the figure open rather than substitute an estimate.
Fix the retention and protection assumptions
The second source of divergence is that each proposal was sized against a different picture of the workload. One assumed shorter retention, another weekly fulls, a third a different growth rate. All change the capacity required, so the comparison has to supply the assumptions rather than receive them.
A short written set is enough: the protected front-end size, the retention required at each tier including long-term restore points, the backup mode in use, expected annual growth, and the immutability window that has to be honored. Every vendor sizes against that same paper, and any deviation appears as a note against their number rather than a silent advantage.
Data reduction deserves its own line because it moves the answer more than anything else. A quote built on an assumed ratio depends on data the vendor has never seen, and the reasonable request is a price at the assumed ratio and a price with no reduction at all. The gap between them is the risk being carried, and treating reduction ratios as claims rather than specifications keeps that risk visible.
What is in scope and what is not
Scope differences are where comparisons quietly break. One proposal includes installation, another assumes the customer racks and cables. One includes switches, another expects existing ones to have free ports. Listing the boundaries and asking each vendor to mark every line as included, chargeable or not applicable turns an argument into a table.
| Question every vendor answers | Why the answers diverge | What a comparable answer looks like |
|---|---|---|
| What usable capacity does this deliver | Raw, usable and effective are used interchangeably | Terabytes writable after the protection scheme, before any reduction |
| What data reduction is assumed | Ratios depend on workload mix and on the backup software already compressing | The assumed ratio stated, plus a price with no reduction assumed |
| What immutability is included | Object Lock may be standard, licensed, or tied to a particular tier | Whether locked capacity is priced as unlocked, and at what retention window |
| What is in year one but billed later | Support, subscriptions and expansion renew on separate clocks | A line per year for three years with renewal terms written out |
| What does the next expansion cost | Expansion is priced when it is needed, not when it is quoted | Price of the smallest increment, and whether today's discount applies to it |
| What does leaving cost | Exit is almost never quoted unless it is asked for | Cost to read all data out, migration help, and hardware return or disposal |
The immutability row deserves attention on a backup target, since a locked object cannot be deleted to make room, and a platform that prices locked capacity differently changes the whole model. The retention window the price assumes belongs next to the price.
Several rows will come back as ranges rather than figures. A range with its condition stated is a usable answer. A single number with no condition attached is the one that later turns out to have answered a different question.
Years two and three, and the price of leaving
Year one is the year vendors compete on, and the least informative. Support renewals, subscription terms, drive replacement policy and the cost of adding capacity all land later, and they are where two quotes that started level separate. A three year view per line item is a routine request, and a refusal to provide one is informative on its own.
Three specific questions do most of the work. What does support cost in years two and three, and what changes if it lapses. What does the smallest expansion increment cost, at what discount, and how long is that price held. And what happens to the software entitlement if the hardware is refreshed before the term ends. Those answers belong in the same three year view the budget is built from rather than in a separate conversation.
The exit is the line most often left blank. Leaving a platform means reading every restore point out of it, which takes network time and may incur retrieval or egress charges. The old platform also stays powered and supported until the new one holds everything, so both are paid for during the overlap. The practical questions resemble the questions asked before moving a repository, and asking them during procurement costs nothing.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on infrastructure the customer runs, in capacities from roughly 50 TB up into the petabyte range. In a comparison it occupies the software-defined column, where the hardware configuration is visible and the usable capacity follows from the protection scheme chosen rather than from a fixed appliance specification.
Immutability is provided through S3 Object Lock and access is through the S3-compatible API, which affects two rows of the comparison directly. The immutability row can be answered in terms of lock mode and retention window rather than a separate product tier, and the exit row can be answered in terms of a standard API that other tools can read from.
ARTESCA is commonly sold through resellers alongside backup software, so a quote may bundle storage, licensing and services together. That is convenient, and it is also where separating the lines matters most, since only separated lines compare against a quote assembled differently.
What the normalized comparison records
The deliverable is one page per option with the same rows in the same order: usable terabytes, cost per usable terabyte per year, the reduction assumption used, the retention and immutability window priced, what is in scope, the three year line items, the expansion increment price and the exit cost. Anything a vendor would not answer is recorded as unanswered rather than filled in.
Underneath that, a short assumptions page records the sizing inputs every vendor was given, so a reader in two years can tell whether a variance came from the platform or from the workload. That page also makes the next procurement faster, since only the numbers need refreshing.
The comparison should be revisited at the first renewal rather than filed. Checking the year two and three figures against what was invoiced, and the usable capacity against what the platform holds, shows which questions were answered well and which need asking differently next time.