Teradata is acquiring Aster Data. Naturally, the deal is being presented with a Treaty of Tordesillas kind of positioning — Teradata does X, Aster Data does Y, and everybody looks forward to having X and Y in the same product portfolio. That said, my initial positioning and product strategy thoughts on the Teradata/Aster combination go something like this.
- The Teradata/Aster combination genuinely is complementary.
- Teradata focuses on and excels at multi-thousand-user, often very operational data warehousing use cases.*
- Teradata’s products also do other analytic DBMS tasks, but in most cases aren’t particularly differentiated at them.
- The use cases Teradata excels at probably can support higher pricing than generic fast-query use cases anyway.
- Aster is focused on analytic platform use cases.
- Aster indeed introduced the first/best vision for analytic platforms.
- Aster Data nCluster isn’t particularly differentiated in, say, general fast-query use cases.
- Aster can command higher prices in analytic platform use cases than generic fast-query ones anyway.
- Recently, Aster has been particularly focused on mapping influence graphs, and not just in the telecom industry where the idea of graph-based churn analysis started.**
- Aster’s old frontline — aka operational — positioning seem like a distant memory.
- Teradata’s and Aster’s core code lines would be very hard to integrate, and hence will not be integrated for the foreseeable future. However:
- Teradata and the Aster Data nCluster DBMS can and should each be enhanced to run exactly the same SQL.
- Aster Data nCluster runs on generic commodity hardware, and that’s great. But the temptation to have Teradata’s hardware engineers design Aster-optimized hardware will eventually become irresistible.
- The Xkoto-based replication Teradata is working on should be extended to Aster Data nCluster.
- There surely will be knowledge transfer between the Teradata and Aster development teams in various areas. (Workload management? Security? Compression, as they both improve in that area?)
*At one point I noticed Teradata reposition the classical EDW as the place for “trusted” analytic data. That’s actually a pretty good way of putting it, sweetening (and watering down) the stifling-EDW-bureaucracy lemons, so as to make them into an appealing lemonade.
**At least one analyst firm has gotten all excited about that, and is positioning Aster pretty much as a social media play. One might call that a case of not seeing the Forrest for the trees — but from a graph-theoretic standpoint, that would be wrong …
Let me say some more about ensuring that the Teradata and Aster product lines run the same SQL. It would probably be a Small Matter of Programming to give Aster nCluster the Teradata temporal SQL extensions; to make Teradata run SQL/MapReduce, for some subset of the programming languages that Aster nCluster supports; and generally to make it so that most new things you’d want to develop on one platform would also run on the other. And since Teradata and Aster seem to be SAS’s two favorite DBMS partners — Teradata for market share and Aster for technology — SAS-support compatibility seems like a reasonable goal as well.
Benefits of such compatibility would include:
- Users could start developing on one platform, then acquire the other one only after they’d dipped their toes in the water.
- In particular, a small-but-noisy group of analysts could be given a virtual slice of a Teradata system to play on until their Aster cluster made it through the budget approval cycle.
- Disaster recovery, archiving, and so on could straddle product lines.
Performance might be very different between the two product lines, of course. And certain programming techniques might not carry over easily, such as user-defined functions (UDF), stored procedures, or some non-SQL analytic processes. Still, all focused and differentiated product positioning notwithstanding, it would be a Very Good Idea to converge the Teradata and Aster platform capabilities faster than is normal in similar merger situations.
Finally, perhaps I should also say more about Teradata’s and Aster’s relative weakness in generic fast-analytic-query use cases.
- There are many use cases for which columnar storage, columnar compression, or both give winning performance. Teradata has a very limited form of columnar compression, and no column storage. Aster has a fairly basic form of column storage, and no columnar compression.
- Teradata is architected more for random than sequential I/O. In row-based systems, sequential I/O is often better for “big” queries.
- While Teradata isn’t as expensive as it used to be — if you’re just running some analytic queries, it’s also not particularly cheap.
- Aster nCluster is just a younger product than many of its competitors. Perhaps there are some use cases for which Bottleneck Whack-A-Mole hasn’t yet gone far enough.
And yes, the rumors about Aster’s customer comScore not getting into production seem to be true, even though comScore talked at the same Aster-sponsored event I did in May, 2010.