Meaning once you have a large enough data set vertically and a sufficiently horizontally fragmented schema doesn’t the scaling fall apart due to the messaging overhead?

Keep in mind , this is in no way a reflection of your product, and to anyone reading this I have no experience with any Asterdata product. I am simply stating characteristics of other distributed systems that are *somewhat* similar to your guys approach. I’m just curious and hopeful!

Thanks!

The biggest difference is in our support for Normalization and fast Joins.

Normalization helps limit data growth rates; de-normalization causes values to be replicated multiple times spurring data growth.

Denormalization is preferred to avoid Joins; it is fair to say that Joins are the slowest component in query execution. We do joins pretty fast even in a distributed environment.

Back to mnesia , the creators have said that the service begins to fail at the petabyte level, have you guys done such theoretical tests?

Regardless, Congratulations! and great product.

We allow you to store all your logs in one database on which queries can be run. The logs can be augmented with contextual information (e.g., information about pages, users, geographies, etc.). We can then use SQL to process data and generate reports. You can also use data-mining tools like SAS, SPSS, and R to analyze data in our database.