In which we bring you another instantiation of Monash’s First Law of Commercial Semantics: Bad jargon drives out good.
When Enterprise DB announced a partnership with Truviso for a “blade,” I naturally assumed they were using the term in a more-or-less standard way, and hence believed that it was more than a “Barney” press release.* Silly me. Rather than referring to something closely akin to “datablade,” EnterpriseDB’s “blade” program turns out to just to be a catchall set of partnerships.
*A “Barney” announcement is one whose entire content boils down to “I love you; you love me.”
According to EnterpriseDB CTO Bob Zurek, the main features of the “blade” program include:
Joint distribution, including distribution by the blade partner of Postgres Plus
Interface between the blade partner and EnterpriseDB’s field organization
Of the 16 blade partnerships announced in the initial press release, only one much resembles the datablade concept. That would be HyperBac, which is offering compression and encryption, as part of high-performance backup. (Bob says HyperBac’s compression reduces exported file size by around 90%, and it’s also extremely fast.) From where I sit, that’s a modified data access method, and hence worthy of the term “blade.”
Bob said that the next closest thing EnterpriseDB has to a true datablade at this time, and getting closer, actually is none of the other 15 partnerships. It’s Oracle compatibility. That makes sense; Oracle compatibility starts in the parser, and might have data access method and hence optimization implications as well. However, in saying this Bob presumably was not counting support for datatypes such as text and geospatial. Unless I’m very wrong about how they’re implemented, those are about as genuine as datablades ever get.