It’s unfortunate that Dataupia has concepts like “Utopia” and “Satori” in its marketing, as those serve to obscure what the company really offers – data warehouse appliances designed for the market’s low end. Indeed, it seems that they’re currently very low-end, because they were just rolled out in May and are correspondingly immature.
Basic aspects include:
- Type 1 appliances, which most other data warehouse appliance vendors (Teradata excepted) have moved away from. And there actually seems to be very little special about the hardware design to take advantage of the proprietary opportunity.
- Apparently limited redistribution of intermediate query result sets – i.e, the “fat head” architecture most competitors have moved away from. But it’s not pure fat-head; there’s some data redistribution.
- General lack of partnerships with the obvious software players (but they’re working on that).
- Low price point ($19,500 per 2-terabyte module).
Beyond price, Dataupia’s one big positive differentiation vs. alternative products is that you don’t write SQL directly to a Dataupia appliance. Rather, you talk to it through the federation capability in your big-brand DBMS, such as Oracle or SQL*Server. Benefits of this approach include:
- Simplicity/ease of adoption.
- Ability to leave some data on the “parent” DBMS and federate queries. This lets you include, say, geospatial data, which Dataupia (and most other appliance vendors) doesn’t handle directly. It could also let you include data that is updated with a frequency the Dataupia appliance doesn’t handle well on its own — i.e., by leaving the frequently-changed tables right on the parent. But there’s a problem that limits the benefit of these capabilities: Joins would have to be done back on the parent database, without any MPP performance advantage from the appliance.
- Ability to run lots of software because it runs on the parent database management system. That said, I suspect the cases in which there will wind up being true plug-and-play transparency will wind up being fairly limited.
Data points about how far along Dataupia is include:
- They’ve announced three OEM customers to date. Two are in the telecom area, one in email (Sendio).
- There are a limited number of production installations to date. All are via the three OEM partners.
- They’ve tested systems up to 100 terabytes. 4-60 terabytes is typical for their OEMs’ end customers.
- They have some enterprise proof-of-concepts. 5-12 terabytes is typical. These seem to be concentrated in usual-suspect industries (retail, telecom). Some of the product development may have been paid for through these. Enterprise deals typically involve service-provider partners.
- They have some compression, but it’s not their strength.
- Encryption is a future feature.
So what are Dataupia’s prospects for success? Well, they don’t seem to have much going for them – at least versus the other vendors with the same (and correct) architectural approach – other than:
A. Low-end/OEM focus.
B. Big-brand transparency.
The more I think about it, the more I like the latter feature. But it’s also not a big problem for anybody else to implement. E.g., just write or license a PL-SQL interpreter or compiler, and you’re most of the way there. I’m sure Ants Software would be eager to help you out; maybe EnterpriseDB could be persuaded as an alternative supplier as well.
So Dataupia’s chances for success boil down mainly to good channel management. OEMs, service provider partners for the enterprise – at least one of those two channels has to blossom for them. Frankly, it’s a bit of a long shot.
On the other hand, they’d make a great acquisition for a BI company or DBMS vendor who could then say “Oh, no, this isn’t a DBMS appliance – it’s merely a data warehouse accelerator.” When you look at it that way, their chances of prospering look distinctly higher.