• Teradata is discontinuing Xkoto’s existing product Gridscale, which Scott characterized as being too OLTP-focused to be a good fit for Teradata. Teradata hopes and expects that existing Xkoto Gridscale customers won’t renew maintenance. (I’m not sure that they’ll even get the option to do so.)
• The point of Teradata’s technology + engineers acquisition of Xkoto is to enhance Teradata’s active-active or multi-active data warehousing capabilities, which it has had in some form for several years.
• In particular, Teradata wants to tie together different products in the Teradata product line. (Note: Those typically all run pretty much the same Teradata database management software, except insofar as they might be on different releases.)
• Scott rattled off all the plausible areas of enhancement, with multiple phrasings – performance, manageability, ease of use, tools, features, etc.
• Teradata plans to have one or two releases based on Xkoto technology in 2011.

Frankly, I’m disappointed at the struggles of clustering efforts such as Xkoto Gridscale or Continuent’s pre-Tungsten products, but if the DBMS vendors meet the same needs themselves, that’s OK too.

The logic behind active-active database implementations actually seems pretty compelling: 

• You may well be keeping a second copy of your database for high availability/hot standby.
• You might even be keeping a third copy for off-site disaster recovery.
• In some cases, you might have reasons beyond disaster recovery to distribute a database around the world.
• So why not allow queries to be run against all the copies?
• And by the way, splitting the workload up a bit by kinds (e.g., long-running vs. short query) might let you optimize the implementation of each copy of the database. (This last point becomes even more important with the rise of solid-state memory.)

Analytic DBMS vendors pretty much all need to offer this. (Possible exception: If they have a data-mart-only positioning so extreme that customers will never care about any form of failover.) That said, I must confess to not having done a good job of tracking who does or doesn’t have which features in this area to date; informative comments to this post in that regard would be much appreciated!

• Xkoto sells Gridscale, a clustering server for DB2 and, more recently, MS SQL Server.
• Xkoto Gridscale runs on a separate box, between the application and the database servers. This box is typically smaller and cheaper than the database server boxes.
• Xkoto most typically sells Gridscale into environments where there already are three database servers — one to do work, one for hot standby, and one for remote disaster recovery.
• In such environments, Gridscale’s big benefit is that you can distribute the query workload among all three servers. Xkoto believes this big performance increase is the reason customers don’t get much past 3 database servers under Xkoto (they didn’t seem quite sure as to whether the all-time record was 4 or 5). Note that even if a remote server is a little too far away for OLTP query response, it can work fine for reporting.
• Of course, if you don’t already have high/”continuous” availability and/or disaster recovery, then Xkoto would say those are core benefits of Gridscale as well.
• Gridscale sends transactions (or just SQL statements?) to all servers in the cluster. Once any of them responds affirmatively, that update is reflected in queries. Gridscale maintains a small query log to make sure it gets the other database copies in sync. It also tries to make sure that queries always go to the most current copy of the database. (I didn’t ask what happens if Server A executes Transaction T but not U, while Server B executes Transaction U and not T — but that does seem like something of an edge case.).
• Xkoto spun out of Halcyon Monitoring in 2006, starting with DB2 support. Microsoft SQL Server support was introduced in 2008.
• Xkoto likes its partnerships with IBM and Microsoft. For example, IBM provides Level 1 and 2 support for Gridscale itself. Due in large part to this partnership strategy, Xkoto says it has no plans to support DBMS beyond DB2 and SQL Server.
• Instead, Xkoto is pursuing partnerships with large application vendors and so on. (The figure “about 10″ was mentioned.) I gather the idea is to make sure that neither the application support folks nor the app itself freak out from the fact that the app isn’t exactly talking to the DBMS any more.
• Xkoto has done lab tests suggesting Gridscale offers near-linear scalability (in terms of SQL Server database throughput) on a query-only workload up to 10 servers.
• I gather that Xkoto and IBM have demos suggesting it’s a fine idea to have your disaster recovery server be in the Amazon cloud, but they haven’t yet made any sales based on that — er, based on that premise.
• Gridscale pricing is measured in the same metrics as DB2 or SQL Server pricing, and in each case is around 1/3 what database pricing would be on the same box (I’m guessing that’s for enterprise additions without add-ons, but I didn’t probe). Specifically, Gridscale charges $12K per 100 PVUs for the DB2 edition, and $12K per socket for running with Microsoft SQL Server.
• Gridscale typically runs on smaller boxes than the databases it talks to.
• Xkoto has about 35 revenue-recognized customers. Most are on DB2, the first environment Gridscale supported.
• Average Gridscale selling prices are $180K on DB2, and $40-50K in the early going for SQL Server.
• Xkoto has about 40 full-time employees, with engineering in Toronto and business operations in Waltham.