September 11, 2009

Xkoto Gridscale highlights

I talked yesterday with cofounders Albert Lee and Ariff Kassam of Xkoto. Highlights included:


15 Responses to “Xkoto Gridscale highlights”

  1. Jerome Pineau on September 11th, 2009 2:56 pm

    Curt, so would this be like one of those “accelerator” sidekick products you once said you recommended against (namely for Dataupia and ParAccel back when they had one) as this layer seems to “emulate” DB2 and SQLServer? Thanks.

  2. Curt Monash on September 11th, 2009 3:15 pm

    Not particularly. When you use Gridscale, the DBMS is still really DB2 or SQL Server.

    And I don’t actively recommend against emulation. I just question how many enterprises find enough value in it to care.

  3. Mark Callaghan on September 12th, 2009 6:37 pm


    How do I recover the query log when the server running Xkoto fails? If it records SQL that has yet to be run on all servers, then I need to make that log highly available.

    How does this guarantee that transactions have the same outcome between servers without serializing transaction execution (for all transactions, or for all that update the same table)?

  4. Curt Monash on September 12th, 2009 6:51 pm


    I didn’t push regarding how bulletproofed Xkoto itself is or isn’t. Between site outages and coughing, I didn’t drag the call out to the extent I usually do.

  5. Tony Bain on September 12th, 2009 9:06 pm

    I was reviewing a start up proposal many years ago that had the idea of replicating SQL statements across nodes to create a scalable system. In general terms, replicating SQL statements seems like a good idea, on the surface. But there are non-deterministic functions that are commonly used in SQL Server database design. Like getdate() is often the default for a date column. With a bit of latency, different replicas would have different values. Also, NEWID() is commonly used to assign a default value to a GUID column. This generates a random GUID so regardless of timing each replica would have different values. Also, stored procedures are commonly used as an interface. Many developers push application logic down into the database so many stored procedures are read/write. This means in theory the whole stored procedure has to run on every node (which is bad if it does a 100,000 row range scan SELECT and then does a one row event table INSERT for example). So it turned out, unless you really architect and develop with this in mind you could end up replicating much of your existing load as you scale. And combined with the point that DBAs can do something similar with transactional replication (updating subscribers) or merge replication and avoid most of these issues, this particular proposal proved a non-starter.

    If Xkoto are following this thread I would be interested if any of the above issues are relevant to them, and if so if they have workarounds/solutions for these sorts of problems. To be clear, I no idea if these sorts of issues are a problem or not for Xkoto. But based on what I read here I am curious as to how they avoid these stuff.

  6. Mark Callaghan on September 13th, 2009 12:38 pm

    Thanks for the PDF. This statement makes me think that write transactions are not run concurrently:
    Each read or write request is sent with an appropriate lock and a sequence number. The
    sequence numbers guarantee that all operations are performed by each database server in
    exactly the same order.

  7. Ariff Kassam on September 14th, 2009 1:01 pm

    Curt, thanks for spending time with us on the phone last week. We appreciate your interest in what is happening at xkoto and GRIDSCALE. To answer some of the questions in the article and in the comments:

    1) Our customers find that the main benefits of GRIDSCALE to be a) continuous availability (the ability to have the application online during planned and unplanned outages) b) horizontal scalability for mostly read applications c) having a functional DR database.

    2) We replicate at the SQL statement level. That is, we send all SQL writes (DML and DDL) to all database servers in the cluster.

    3) I wouldn’t say that we’ll never support another database platform. We’re currently talking to our customers to see what other features or database platforms they would like added or supported by GRIDSCALE.

    4) We cluster the GRIDSCALE servers for availability using our own clustering mechanisms. The Recovery Log is replicated between the GRIDSCALE servers.

    5) For non-deterministic functions: a) if the non-deterministic function call flows through GRIDSCALE, it will automatically replace the call with a deterministic value set by the GRIDSCALE server before the SQL is sent to all the database servers. b) if the non-deterministic function happens in the database (e.g. SP, trigger, etc.) we provide functions that can be used in place of the default functions to provide the same functionality but consistent values across the database servers.

    There are a number of debates on the benefits/disadvantages of placing application logic within the database. With GRIDSCALE, the scalability benefits are from being able to load balance queries. If the application is simply executing SPs which do both reads and writes, the scalability benefits will be limited. However, a lot of our customers feel that the scalability benefits are secondary. The availability benefits are the priority. Since GRIDSCALE operates at the SQL level, we allow customers to perform database maintenance, version migrations, etc. without application outages.

    The main differences between GRIDSCALE and transaction/merge replication is that GRIDSCALE provides consistent read access across all the database servers and it is easier to setup/manage.

    6) To guarantee order of updates across the servers, write statements are serialized based on primary (or unique columns) access.

  8. Robert Wagner on May 12th, 2010 11:38 pm

    Hi Curt,

    Do you have any news on xkoto? Their website doesn’t have any recent postings, and some material has been taken down (e.g. Management Team).


  9. Curt Monash on May 12th, 2010 11:55 pm


    Nope. Haven’t heard from them quite a while. Tweeting PR guy Mel Webster to ask.

  10. Rick on May 13th, 2010 12:30 am

    I just heard that Xkoto sold out to Teradata, and that Teradata will no longer support the product. If this is true, what a shame! I was very excited for this product as it gave DB2 an edge over Oracle in the long distance HA department.

    And shame on IBM for not buying them first! They will be regretting that slip…

  11. Anton on May 17th, 2010 10:19 am

    Indeed the sale of XKoto to Teradata is true, and yes, what a shame. Rick, I totally agree with you.

  12. Yunfeng Sun on July 18th, 2010 9:51 pm

    Hi Curt, Will you comment on Teradata’s acquisition of xkoto?

  13. Curt Monash on July 19th, 2010 12:07 am

    Teradata said they’d brief me, then refused, then probably forgot about it after changing direction again as to how much they’d disclose.

  14. Stephen Sun on July 20th, 2010 6:53 am

    IBM is now focusing on its own product, pureScale. And I believe IBM will finally grow up pureScale to have similar capability as GridScale, that is, not only a HA solution, but also includes DR.

  15. Teradata, Xkoto Gridscale (RIP), and active-active clustering | DBMS2 -- DataBase Management System Services on July 31st, 2010 4:24 am

    […] is discontinuing Xkoto’s existing product Gridscale, which Scott characterized as being too OLTP-focused to be […]

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.