Normally I only really glance at a company or software's "feature comparison" chart. Mostly because they are blatantly skewed to their own by ignoring options they don't provide or support. But occasionally I run across some egregious misrepresentations. Today I ran across one.
A prime example of how not to make a "feature comparison chart" can be found at Iron.io's feature comparison page for IronCache. Not only do they attempt to compare a service with a data store (ie. comparing an apple to a bunch of bananas), they get several items completely incorrect. In no particular cub-order I'll highlight some of them, beginning with the more egregious: the factually incorrect ones.
First up they list Redis and Managed Redis offerings as not offering persistence. Anyone who spends about one minute or so on the Redis site knows Redis is persistent. The default configuration file has persistence enabled. Further, nearly all redis host providers have it, ranging from RedisToGo, to RedisLabs, Rackspace, and Amazon just to name a few.
Next, "High Availability". Redis has replication and Sentinel, providing HA. Further, Managed providers such as Rackspace and RedisLabs offer highly available Redis (each vie different methods so you can pick your solution). Thus they get this one incorrect as well.
"Redundant/Failover". First this sounds a lot like "HA". Second, again Redis has both of these via Replication and Sentinel. As you might surmise given that Redis has it, you can get Managed Redis providers with this as well. As with HA you can take multiple routes and get this from multiple providers.
"Backed up". Here we get into committing the error of comparing a software product with a service offering. However, a cursory look at Redis providers will easily demonstrate you get backed up Redis offerings at both Rackspace and RedisLabs - to name a couple.
Related to this is "Long term Storage". This is essentially a made-up phrase. Consider their marking Redis as not being persistent, not backed up, not redundant. Yet they give it a yes mark here. So, in memory counts as "long term storage"? Not in my book. But Redis has persistence and replication so they do get it correct even if the term isn't sensical.
This brings us to the weasel-like portion of it. Let us start with "Shareable". What does that mean? They don't say, they simply claim that Redis, Memcached, and providers thereof don't have it. Well, given most common understanding of what shareable can mean in a remote cache - that line should have green checkmarks across the board. All you need is the connection string and authentication credentials and you can "share" the cache.
"Elastic" is also left to your imagination, but they are apparently the only ones with it, despite Amazon's ElastiCache offering.
Much of the rest of the table is making the mistake of comparing a service to a product. Yet even there they get it incorrect. They allege only they have dashboards, email reports, reporting, and analytics. Yet Redis providers, to varying degrees, also have these. Thus, they are incorrect for most of these as well.
There are some simple corrections to be made to make this table non-egregious and a prime example of how not to compare your product with other things.
1: Don't compare a service with a product. This should be pretty simple and should go without needing to be said.
2: Be accurate in your comparison. Marking your "competition" as not having something they do have is probably the worst thing you can do. At best it shows you are bad at market research and at worst are intentionally making fraudulent marketing statements.
3: Don't make up phrases or mis-use common ones to claim only you have it, then fail to explain what you mean. Instead use common phrases they way they are already used in the industry and explain in detail if you stray from it.
I have no knowledge of how IronCache performs as I only ran across them today. I only know what I've read on their website. However this table leaves a bitter taste in my mouth regarding the company given how terribly wrong it is. I'm certain that was not the intended result, and I do hope they correct their table and properly vet future iterations of it.