• The Forrester Wave’s relative vendor rankings are meaningless, in that the document compares apples, peaches, almonds, and peanuts. Apparently, it covers any vendor that includes a distribution of Apache Hadoop MapReduce into something it offers, and that offered at least two (not necessarily full production) references for same.
• The Forrester Wave for “enterprise Hadoop” contradicts itself on the subject of Hortonworks.
  • The Forrester Wave for “enterprise Hadoop” is correct when it says “Hortonworks … has Hadoop training and professional services offerings that are still embryonic.”
  • Peculiarly, the Forrester Wave for “enterprise Hadoop” also says “Hortonworks offers an impressive Hadoop professional services portfolio”. Hortonworks will likely win one or more nice partnership deals with vendors in adjacent fields, but even so its professional services capabilities are … well, a good word might be “embryonic”.
• Forrester Waves always seem to have weird implicit definitions of “data warehousing”. This one is no exception.
• Forrester gave top marks in “Functionality” to 11 of 13 “enterprise Hadoop” vendors. This seems odd.
• I don’t know why MapR, which doesn’t like HDFS (Hadoop Distributed File System), got top marks in “Subproject integration”.
• Forrester gave top marks in “Storage” to Datameer. It also gave higher marks to MapR than to EMC Greenplum, even though EMC Greenplum’s technology is a superset of MapR’s. Very strange. (Edit: Actually, as per a comment below, there is some uncertainty about the EMC/MapR relationship.)
• Forrester gave higher marks in “Acceleration and optimization” to Hortonworks than to Cloudera and IBM, and higher marks yet to Pentaho. Very odd.
• I’m not sure what Forrester is calling a “Distributed EDW file store connector”, but it sounds like something that Cloudera has provided via partnership to a number of analytic DBMS vendors.
• Forrester’s “Strategy” rankings seem to correlate to a metric of “We’re a large enough vendor to go in N directions at once”, for various values of N.
• Forrester is correct to rank Cloudera’s “Adoption” as being stronger than EMC/Greenplum’s or MapR’s. But Hortonworks’ strong mark for “Adoption” baffles me.

This post is a moderately edited form of an actual interview. Two other posts cover analytic trends to watch (planned) and analytic vendor execution challenges to watch (already up).

Question: What do you think will happen next year with the Tableaus of the world?

Answer:

• I think adoption of flexible-visualization business intelligence tools will continue to be rapid.
• I think enterprise-friendly features will be increasingly important as a basis of competition.

Question: What do you mean by “enterprise-friendly”?

Answer: An example would be QlikTech no longer forcing you to use their native ETL, but rather working with Informatica and soon other third-party products. Also important can be:

• Database size.
• Concurrency.
• A full-featured development cycle for analytic applications.

Question: What does HP have to do to be relevant in analytics/data warehousing?

Answer: Avoid stupidity. HP Vertica is already relevant.

Question: OK. But what can HP do to build on Vertica?

Answer: HP — which botched Exadata 1 hardware — could do a good job with SAP HANA or other kinds of appliance products.

However:

• I don’t think trying to force Vertica beyond its natural growth — the way EMC is with Greenplum — is necessarily a good idea. Natural growth in Vertica’s case is plenty fast anyway.
• Obviously, making good Vertica hardware would be nice. But being hardware-independent is crucial to Vertica, not least because of cloud deployment, an option many buyers want to at least have in their hip pockets.

Question: You expressed some skepticism toward mobile BI/use cases. Why so?

Answer: The form factor hurts functionality a lot, so it’s only worthwhile in cases where timeliness is key.

And without more refined alert-setting functionality, it’s hard to think of that many cases.

Note: My views on mobile BI haven’t changed much since July, 2010.

Question: What about the idea of an enterprise being able to pay-per-drink to run jobs on an analytic cluster. Do you expect that concept to have any legs in 2012?

Answer: While other kinds of SaaS (Software as a Service) BI might make sense, remote computing BI that focuses on hardware cost sharing is problematic. Moving data in and out of the cluster is a big part of the overall cost, at least if you plan to process it only occasionally once it gets there. I haven’t seen a plan yet that gets around that point.

2. That said, the Hadoop part of EMC ‘s story is based on MapR, which so far as I can tell is actually a pretty good Hadoop implementation. More precisely, MapR makes strong claims about performance and so on, and Apache Hadoop folks don’t reply “MapR is full of &#$!” Rather, they say “We’re going to close the gap with MapR a lot faster than the MapR folks like to think — and by the way, guys, thanks for the butt-kick.” A lot more precision about MapR may be found in this M. C. Srivas SlideShare.

3. On its latest earnings call, Oracle clearly said it would introduce a Hadoop appliance, versus just hinting at a Hadoop appliance the prior quarter. The money quote was: 

Finally, big data or the searching of large amounts of data using Hadoop. After Hadoop finishes filtering the data, the place you want to put that data is an Oracle Database, and that’s what a lot of our customers are doing. And we are exploiting the trend, the big data technology and the big data trend, if you prefer, by building a Hadoop appliance that attaches to the Oracle Exadata database or any Oracle Database for that matter. But you don’t have to buy our Hadoop appliance if you can use whatever servers you want running Hadoop, and we provide the interface between Hadoop and the Oracle Database.

In other words, Oracle is saying “We’d like to sell you a Hadoop appliance, but you can run Hadoop in some other way and we’ll coexist with it just fine.” That makes sense; refusing to coexist with Hadoop is not exactly a realistic option.

4. Back in June, I expressed great skepticism about the idea of a Hadoop appliance. There was at least partial pushback in the comment thread from both Amr Awadallah and Eric Baldeschwieler. Oops.

Their reasoning seems to be centered around matters of installation, administration, and general packaging.

5. A month ago I noted aggressive near-term plans for Apache Hadoop evolution. As noted above, one reason this is needed is competition from folks like MapR. Also, I note that:

• Three years ago, Oliver Ratzesberger’s group at eBay complained that CPU utilization running Hadoop was at 18%.
• Now Oliver uses a figure of 10-15%., and attributes an even lower figure to — I’m guessing here — Yahoo. (Another possibility might be Facebook.)
• In between eBay became one of the biggest and most prominent users of Hadoop.

The moral of eBay’s Hadoop adventures, as I see it, is neither “Hadoop sucks!” nor “Hadoop doesn’t suck!”; rather, it’s that there’s a lot of scope for Hadoop to operate differently in the future than it does today.

Similarly, whatever throughput Yahoo does or doesn’t get, it clearly has adopted Hadoop at the expense of the columnar-in-Postgres system it previously was so proud of.

Also, there has been a claim going around that — notwithstanding NameNode’s status as a single point of Hadoop failure —  no Hadoop installation has ever lost data due to a NameNode failure. The folks at MapR beg to differ, and sent over some links that sure seem to say the opposite.

6. Since we’ve just established that Hadoop will change, rapidly and pretty fundamentally, what exactly is the benefit of an appliance that is “balanced” for Hadoop usage today?

The present invention relates to data storage, and more particularly, to methods and systems for a high throughput storage device.

A form of on-line transaction processing (OLTP) applications requiring a high number of data block reads or writes are called H-OLTP applications. A large server or mainframe or several servers typically host an H-OLTP application. Typically, these applications involve the use of a real time operating system, a relational database, optical fiber based networking, distributed communications facilities to a user community, and the application itself. Storage solutions for these applications use a combination of mechanical disk drives and cached memory under stored program control. The techniques for the storage management of H-OLTP applications can use redundant file storage algorithms on multiple disk drives, memory cache replications, data coherency algorithms, and/or load balancing.

and ends

It would be desirable for large capacity storage to provide sufficient throughput for high-volume, real-time applications, especially, for example in emerging applications in financial, defense, research, customer management, and homeland security areas.

The independent claims are:

1. A storage system comprising: one or more memory sections, including one or more memory devices including storage locations that store data, and a memory section controller that provides addresses to the memory devices, the addresses identifying storage locations for a memory device, wherein the memory devices use the provided addresses to perform a function selected from the set of reading out and writing data to/from the memory devices; and one or more switches, comprising a configurable switch fabric, that receive a data request including a data block identifier and switch the data request to one or more of the memory sections determined by applying the data block identifier to an algorithm that selectively configures operation of the switch fabric, the data block identifier identifying a set of storage locations; wherein the memory sections to which the data request was switched forward the received data block identifier to its memory section controller which maps the data block identifier to a set of addresses for the storage locations identified by the data block identifier, and provides the set of addresses to one or more of the memory section’s memory devices.
…
16. A method for use in a storage system, comprising: storing data in storage locations in a memory device; receiving by a switch comprising a configurable switch fabric, a data request including a data block identifier; the switch switching the data request to a memory section including the memory device determined by applying the data block identifier to an algorithm that selectively configures operation of the switch, the data block identifier identifying a set of storage locations in the memory device; forwarding the received data block identifier to a memory section controller; the memory section controller mapping the data block identifier to a set of addresses for the storage locations identified by the data block identifier; and the memory section controller providing the set of addresses to the memory device; and the memory device using the provided addresses to perform a function selected from the set of reading and writing data to/from the memory device.
…
26. A storage system, comprising: means for storing, including: means for storing data in storage locations, the means for storing data in storage locations including means for reading data stored in the storage locations using an address; means for controlling the means for storing, the means for controlling including: means for mapping a data block identifier to a set of addresses, means for providing the addresses to the means for storing data in storage locations, the addresses identifying storage locations; means for switching, including means for receiving a data request including a data block identifier; means for switching the data request based on the data block identifier to a means for storing determined by applying the data block identifier to an algorithm that selectively configures operation of the means for switching, the data block identifier identifying a set of storage locations in the means for storing data in storage locations; and means for forwarding the received data block identifier to the means for storing.

27. A storage hub comprising a memory section, including a memory device including storage locations that store data, and a memory section controller that provides an address to the memory device, the address identifying a storage location, wherein the memory device uses the provided address to write data into the memory device; and a switch, comprising a configurable switch fabric, that receives a data request including a data block identifier and transmits the data request to the memory section determined by applying the data block identifier to an algorithm that selectively configures operation of the switch fabric, and that receives write data associated with the data request and transmits the write data to the determined memory section; wherein the memory section forwards the received data block identifier to the memory section controller, which determines from the data block identifier the address of a storage location and provides the address to the memory device, and the memory device stores the write data at the address.

My one thought that could have led to the patent making sense was that maybe the term “configurable switch fabric” was defined in some particularly limited way. But noooo. Indeed, the term is not defined in the patent’s body at all; rather, the patent says (somewhat ungrammatically):

The switches 22 may be any type of switch using any type of switch fabric, such as, for example, a time division multiplexed fabric or a space division multiplexed fabric. As used herein, the term “switch fabric” the physical interconnection architecture that directs data from an incoming interface to an outgoing interface. For example, the switches 22 may be a Fibre Channel switch, an ATM switch, a switched fast Ethernet switch, a switched FDDI switch, or any other type of switch. The switches 22 may also include a controller (not shown) for controlling the switch.

I would be shocked if this patent held up upon reexamination. (If it did, EMC would pretty much be out of business, or at least vulnerable to a considerable cashectomy.) This is a particularly strong example of my belief that performance-enhancement software patents are always bogus. What’s more, it seems strange to worry about this patent’s effect on HDFS in any case, because if you’re that much of a patent wimp, you probably don’t want to run afoul of Google’s (also bogus) MapReduce patent in the first place.

On the whole, I’m somewhat more sympathetic to the idea of replacing HDFS underneath Hadoop than my clients at Cloudera or IBM would wish me to be. But the Parallel Iron patent is not a serious reason in support of such a change.

Known HDFS and Hadoop data storage and management issues include but are not limited to:

• Hadoop is run by a master node, and specifically a namenode, that’s a single point of failure.
• HDFS compression could be better.
• HDFS likes to store three copies of everything, whereas many DBMS and file systems are satisfied with two.
• Hive (the canonical way to do SQL joins and so on in Hadoop) is slow.

Different entities have different ideas about how such deficiencies should be addressed. 

For most practical purposes, Yahoo’s and IBM’s views about Hadoop have converged. Yahoo and IBM both believe that Hadoop data storage should be advanced solely through the Apache Hadoop open source process. In particular:

• IBM and Yahoo both talk of the great undesirability of Hadoop “forking” like Unix did.
• Yahoo appeared on stage at IBM’s analyst event this week to reinforce the meeting-of-the-minds, even though there’s no IBM/Yahoo customer relationship involved.
• IBM has disclaimed any intention of providing its own Hadoop distribution, but even so is committed to selling lots of IBM InfoSphere BigInsights, which incorporates Apache Hadoop.*
• Yahoo has stopped offering its own Hadoop distribution, period.

*IBM is emphatic about ruling out marketing terms whose connotation it doesn’t like. IBM’s Hadoop distribution isn’t a “distribution,” because that might make it sound too proprietary; IBM’s Oracle emulation offering isn’t an “emulation” offering, because that might make it sound too slow; and IBM’s CEP product InfoSphere Streams isn’t a “CEP” product, because that might make it sound too non-functional.

Cloudera can probably be regarded as part of the Yahoo/IBM camp, some stern looks from IBM in Cloudera’s direction notwithstanding. Cloudera Enterprise — also an embrace-and-extend offering — remains the obvious choice for enterprises Hadoop users; meanwhile, nobody has convinced me of any bogosity in the “no forking” claim Cloudera makes for its free/open source Hadoop distribution. Indeed, when I visited Cloudera a couple of weeks ago, Mike Olson showed me a slide demonstrating that Cloudera might be supplanting Yahoo as the biggest ongoing contributor to Apache Hadoop.

EMC’s Data Computing Division, nee’ Greenplum, made a lot of Hadoop noise this week. Unlike Yahoo, IBM, and Cloudera, EMC really is forking Hadoop. I’m not talking with the EMC/Greenplum folks these days, but the whole thing was covered from various angles by Lucas Mearian, Doug Henschen, Derrick Harris, and Dave Menninger.

Another option is to entirely replace HDFS with a DBMS, whether distributed or just instanced at each node. DataStax is doing that with Cassandra-based Brisk; Hadapt plans to do that with PostgreSQL and VectorWise (edit: As per the comment below, Hadapt only plans a partial replacement of HDFS); and Netezza’s analytic platform has a Hadoop-over-Netezza option as well. Mike Olson objects to such implementations being called “Hadoop”; but trademark issues aside, those vendors plan to support a broad variety of Hadoop-compatible tools. Aster Data has long taken that approach one step further, by offering an enhanced version of MapReduce — aka SQL/MapReduce — over its nCluster DBMS. And 10gen offers a more primitive form of MapReduce with MongoDB, but probably wouldn’t position it as addressing a “MapReduce market” at all.

• SAS no longer plans to go as far with in-database modeling as it previously intended.
• Rather, SAS plans to run in RAM on MPP DBMS appliances, exploiting MPI (Message Passing Interface).

The whole thing is called SAS HPA (High-Performance Analytics), in an obvious reference to HPC (High-Performance Computing). It will run initially on RAM-heavy appliances from Teradata and EMC Greenplum.

A lot of what’s going on here is that SAS found it annoyingly difficult to parallelize modeling within the framework of a massively parallel DBMS such as Teradata. Notes on that aspect include:

• SAS wasn’t exploiting the capabilities of individual DBMS to their fullest; rather, it was looking for an approach that would work across multiple brands of DBMS. Thus, for example, the fact that Aster’s analytic platform architecture is more flexible or powerful than Teradata’s didn’t help much with making SAS run within the Aster nCluster database.
• Notwithstanding everything else, SAS did make a certain set of modeling procedures run in-database.
• SAS’ previous plans to run in-database modeling in Aster and/or Netezza DBMS may never come to fruition.

SAS’ problems developing in-database modeling stem from, in essence, the limitations of UDFs (User Defined Functions). So why weren’t, for example, Teradata’s 2009 enhancements to its UDF capabilities enough? The clearest example SAS gave me is that, while database tables are commonly limited to something on the order of 1000 columns (their figure as well as mine), SAS might need 50-100,000 columns. One reason seems to be interactions between variables; SAS used the word “multiplied” a few times, but even so was coy about whether this could simply be regarded as quadratic terms in a regression. Another reason seems to be that in some cases, every value in a column spawns a new column in an intermediate table/array; indeed, this seems to be going on in the previously discussed case of logistic regression.

SAS code will be launched by the DBMS/data warehouse appliances, so potentially it can run under their native workload management. Teradata presumably has enough workload management richness to exploit that; EMC Greenplum, as of my August 2010 notes, probably did not.

SAS was gracious enough to let me post its slide deck, in both shorter and longer versions. Due to a technical glitch during the call, I neither looked at the slides nor took notes. I think the biggest loss from those difficulties is that I didn’t learn what the futures at the end of the longer deck were all about.

Related links

• Application areas for SAS HPA (April, 2011)
• SAS’ MPP story as of May, 2010
• SAS’ plans to run in-database on Teradata (October, 2007)

• EMC Greenplum’s* revenue target for Q1 had been $35 million.
• Actual EMC Greenplum revenue for Q1 was $3 million, or maybe it was $8 million.
• EMC Greenplum had 75 sales teams trying to generate this revenue.

In the past I might have called Greenplum for clarification, but they’re not knocking themselves out to inform me these days, nor to inspire me with confidence in what they say. 

*I’m in the large majority that refers to the EMC Data Computing Division as “Greenplum” or “EMC Greenplum.”

Let’s unpack that a bit.

First, it makes a huge difference whether we’re talking about:

• All EMC sales Greenplum can be said to influence.
• All Greenplum software and appliance hardware.
• New Greenplum software and subscription recognized revenue also.

Indeed, pre-EMC Greenplum got a considerable fraction of its revenue on a subscription basis. One implication is that “license revenue” and “new-sale license revenue” aren’t the same figure. Another is that the difference in immediate revenue between an appliance sale and a software-only subscription is drastic (8X alone for the difference between quarterly subscription and perpetual license fee, times another factor for the inclusion of hardware).

I’m also having a bit of trouble swallowing that supposed $35 million target. If we recall that the quota for the sum is always less than the sum of the quotas, we’re talking about perhaps a $5-600K quota per team. That could be reasonable or even low for a fully productive team that’s selling hardware and software together (even in a Q1). But if there really are anywhere near that many Greenplum sales teams, then a large majority are really new. And data warehouse appliances (more so than just analytic DBMS) have long sales cycles.

Bottom line: I haven’t heard anything that suggests EMC Greenplum’s storage-vs.-DBMS strategic war is going well. But I also wouldn’t assume things are quite as grim as rumors suggest.

• EMC Greenplum no longer uses my services.
• EMC Greenplum no longer briefs me.
• EMC Greenplum reneged on a commitment to fund an effort in the area of privacy.

The last one really hurt, because in trusting them, I put in quite a bit of effort, and discussed their promise with quite a few other people.

Yes, that five-word sentence really seems to have been the problem. I’ve heard that from more than one source.

I think the rest is overwrought too, and not just because I regret the loss of revenue, or of what seemed to be a warm, friendly, hug-laden, and sushi-intensive relationship with Scott Yara and some other folks. At various times, on the subject of its eBay installation:

• Greenplum overoptimistically told me that eBay’s Teradata installation would be replaced with Greenplum gear.
• Greenplum exaggerated the pace of its eBay installation; unfortunately, I believed them, and later had to publish a retraction.
• Greenplum neglected to tell me when eBay had its Greenplum equipment removed.

Now the same Scott Yara who hovered over me for months in marketing micromanagement before I broke the news of the Greenplum and Teradata eBay installations — he could do that because the whole discussion started out under NDA — doesn’t answer my email. Evidently, Greenplum thinks it’s OK to repeatedly be misleading, but doesn’t think it’s OK if my nuance is one they disagree with.

The most entertaining example I recall of Greenplum BS was when CTO Luke Lonergan told 50+ academics at the 2009 XLDB that Greenplum had 10 customers with half a petabyte each of data. I followed him out of the room and said “10 customers — half a petabyte each — I presume that’s for sufficiently small values of ‘one half’?” We eventually settled on a value of “one half” in the 0.2 range — which is actually a pretty impressive claim in itself.

Be all that as it may, EMC Greenplum has a couple of press releases out on which I’ve been asked to comment. One is a deal with SAS, less impressive than SAS’ deals with Teradata and Aster Data in that it offers no actual in-database modeling. Yes, it sounds like modeling on the same nodes where the data sits, but it sounds less desirable than true in-database modeling in that:

• You can only get great performance if the amount of data modeled is small enough to fit into RAM.
• Integration with other database processing, MapReduce, etc. may be limited.

Also, EMC Greenplum expanded its line of appliances, to include one that seems optimized for price-per-terabyte and one with solid-state drives. So far, that’s very standard stuff. There’s also a new data loading appliance, which seems to catch up with the Aster Data’s 2008 strategy of having separate nodes for bulk loading.

Ironically, when Aster moved away from a total reliance on that strategy, it was becoming more Greenplum-like. As is so often the case, it seems that different vendors’ feature sets are converging.

Meanwhile, the last I heard about Greenplum’s previously very strategic Chorus effort is that it’s being revamped. I don’t get the impression it’s nearly as central to Greenplum’s strategy as it used to be.

• This is a list of Monash Advantage members.
• All our vendor clients are Monash Advantage members, unless …
• … we work with them primarily in their capacity as technology users. (A large fraction of our user clients happen to be SaaS vendors.)
• We do not usually disclose our user clients.
• We do not usually disclose our venture capital clients, nor those who invest in publicly-traded securities.
• Included in the list below are two expired Monash Advantage members who haven’t said they will renew, as mentioned in my recent post on analyst bias. (You can probably imagine a couple of reasons for that obfuscation.)

With that said, our vendor client disclosures at this time are:

• Aster Data
• Cloudera
• CodeFutures/dbShards
• Couchbase
• EMC/Greenplum
• Endeca
• IBM/Netezza
• Infobright
• Intel
• MarkLogic
• ParAccel
• QlikTech
• salesforce.com/database.com
• SAND Technology
• SAP/Sybase
• Schooner Information Technology
• Skytide
• Splunk
• Teradata
• Vertica

That list includes the two I’m obfuscating, plus one more who just emailed to say a signed renewal contract is arriving this week. It does not include others who, less concretely, have said they will sign up soon.

Also, I guess there’s a bit of a gray area for Tableau. As far as I’m concerned, I’m doing an upcoming co-sponsored webinar just for Monash Advantage member Aster Data. Indeed, I declined to contract with or bill Tableau directly for its share,  because I had no good way to do that paperwork. But even so, Tableau is a cosponsor, was involved in the planning discussions and, behind the scenes, is surely footing part of the bill.

*At the time of this writing, I don’t have a link to a free version of the full report. At the time of this writing, the 2011 Forrester Wave for Enterprise Data Warehouse Platforms graphic can be found here.

One example of the confusion pervading the 2011 Forrester Wave for Enterprise Data Warehouse Platforms lies in a list of three supposed trends.

• The Forrester Wave somehow conflates SaaS and MPP processing, tying them both to the term “cloud.” (In reality, the SaaS/cloud and MPP/cloud equations depend on two rather different word-senses for “cloud”.)
• The Forrester Wave then conflates EDWs, analytic computing systems, and application servers, the latter perhaps because of the “data-application server” product category name Aster Data floated. The Forrester Wave also conflates investigative analytics with low-latency operational processes that exploit investigative analytics’ results.
• The Forrester Wave then conflates social media, “unstructured data” (by which it seems at one point to mean text and at another point to also mean logs), solid-state drives, and a whole bunch of other technologies (especially but not only low-latency ones) into another supposed single trend.

Some of the sillier specific claims in the Forrester Wave for Enterprise Data Warehouse Platforms include:

• According to the 2011 Forrester Wave for Enterprise Data Warehouse Platforms, Netezza has hybrid row/columnar persistence, while most other vendors cited don’t. To recycle an old Larry Ellison joke, somebody obviously has a better pharmacist than I do. It’s tough to imagine how anybody who understands columnar storage could at all believe Netezza currently offers it.
• According to the 2011 Forrester Wave for Enterprise Data Warehouse Platforms, EMC/Greenplum is limited in the hardware it supports. Actually, Greenplum runs on pretty much any commodity Intel hardware, just like any other software-only DBMS does.
• According to the 2011 Forrester Wave for Enterprise Data Warehouse Platforms, Teradata, Sybase, and others are differentiated in their Hadoop support. Actually, Hadoop support of various forms is a checkmark item for analytic DBMS vendors.
• According to the 2011 Forrester Wave for Enterprise Data Warehouse Platforms, Oracle, Teradata, and others are differentiated in their cloud/SaaS support. Actually, having some kind of public cloud offering is a checkmark item; use of same is quite a different matter.
• The 2011 Forrester Wave for Enterprise Data Warehouse Platforms calls out EMC Greenplum for special praise in mixed workload management. Greenplum will probably be fine in concurrency and workload management, but implying it’s a leader is overstated.
• According to the 2011 Forrester Wave for Enterprise Data Warehouse Platforms, Vertica has not made a significant investment in real-time technologies (despite doing a lot of work with StreamBase and selling a lot into the algorithmic trading market). I disagree.
• Also according to the 2011 Forrester Wave for Enterprise Data Warehouse Platforms, Vertica has not made a significant investment in in-memory technology, despite the fact that all its updates pass through Vertica’s in-memory, query-responsive “Write-Optimized Store.” I disagree.

Even leaving aside the errors that obviously riddled the Forrester Wave for Enterprise Data Warehouse Platforms’ underlying 56-row matrix, I dispute the whole premise of the exercise. I’m not a big fan of overarching scorecard-based rankings, because the right choice of product varies so much by use case. For example:

• If you’re a smallish enterprise who can realistically do OLTP and data warehousing on the same instance of your DBMS, Oracle and Microsoft blow away everybody else mentioned.
• If columnar compression methods work really well for your use case, Vertica or maybe Oracle Exadata might shine.
• If you typically only retrieve a few columns from a wide table, so that columnar I/O is what you care most about, Vertica, Sybase, or even EMC Greenplum might shine. (The decidedly non-columnar Netezza and Oracle Exadata approaches to predicate pushdown might or might not excel as well.)
• If your database is above a certain size, some of the alternatives (such as Sybase IQ or non-Exadata Oracle) should be taken off the table.
• If you have a highly concurrent mixed workload, nobody else is as proven as Teradata.
• If you don’t want to invest much in database administration, Oracle is about the last vendor you should consider, and Netezza might be the first.

More excusable is some terminological confusion in the Forrester Wave for Enterprise Data Warehouse Platforms, the essence of which is this:

Notwithstanding its name, the Forrester Wave for Enterprise Data Warehouse Platforms isn’t just talking about what are called enterprise data warehouses (EDWs), but rather a broader range of analytic database management systems and use cases. These include:

• What are classically called operational data stores (the focus on “Next-Best Actions” suggests those are included).
• Analytic platforms/analytic computing systems (the high-level mentions of MapReduce, predictive modeling integration, and so on suggest they’re in too).
• Reporting data marts (some of the vendors cited might not make the minimum count threshold unless those are included too).

Indeed, the definition provided of “EDW” basically boils down to “runs SQL, is tuned in some way for analytics, has a cost-based or other query optimizer, and isn’t tied to a specific application.”

Frankly, I think classical EDWs have their problems, and are not necessarily the best way to address the numerous use cases for analytic DBMS technology. And product category names are commonly problematic anyhow. So I don’t much mind this overloading of the EDW term. But in one respect I think the Forrester Wave overdoes its inclusiveness — it includes things that aren’t actually DBMS, and then marks down just about every product cited for being a real DBMS rather than some sort of above-DBMS layer, at least when those things are sold by SAP. I’ve never agreed with the idea that SAP’s BW/BWA products should be included in a comparison with the other products cited in the Forrester Wave at all, and SAP HANA doesn’t change my mind.

One last thing — I’m suspicious of the Forrester Wave for Enterprise Data Warehouse Platforms’ comments on data warehouse appliance prices. However, they are hard to judge without knowing whether Forrester was using the term “raw data” in its usual sense, or actually means “user data”, and also without knowing whether Forrester is talking about list or “street” pricing.