Documentation Overview

CurvanadeMobile under the hood


In CurvanadeMobile version 1.0 we provide CRUDIS (Create, Read, Update, Delete, Indexing, Search) and Batch upload of  data.
All objects stored in CurvanadeMobile are stored as JSON allowing for simple access independent of client.
CurvanadeMobile is focused on providing a real simple data interface that scales and is easy to use across platforms regardless of architecture.

What CurvanadeMobile is under the hood

Under the hood CurvanadeMobile is a NOSQL keyvalue graph database that makes it possible to store and index data. It is built for Big Data! It has an implementation of the MapReduce concept for distributed data storage. It is also has an implementation that supports distributed execution of code associated with data storage in the form of Read, Map, Reduce, Combine, Write and Filter functions.

CurvanadeMobile use a combination of AzureTables, SQLAzure, and BlobStorage to store data and deliver a high speed search that will take the breath out of most users. It has the power to store and search a huge amount of data with a performance over a 1000 times a traditional Relational database. Our own high-performance, NOSQL graph database is 100% on Windows Azure. We see it as Cassandra for Windows Azure. 

How do CurvanadeMobile run?

CurvanadeMobile creates a dynamic storage and computing GRID made up of a set of Clusters where each cluster is a Windows Azure deployment connected to the GRID controller. Each deployment contains one or more instances. These deployments may be in different datacenters and use different storage partitions.

An optional single cluster mode allows CurvanadeMobile to run in a single Azure deployment as a local cluster acting as its own GRID controller effectively scaling data access and computations. This is for Customers that have laws or internal regulations that creates the need to run it all on their own instances.

The storage used is dynamically reconfigurable to use AzureTables, SQLServer or BlobStorage or any combination thereof as persisters. Sharding is both mandatory and supported across all storages.

Social Extensions (upcoming)

As you can see in, CurvanadeMobile takes care of Users, creating of Accounts, integration with Facebook, Events and more. How is this done? Is it some thing created specially for this web and mobile app application/site? No it is not. It is built in to CurvanadeMobile we call it Social Extension.

Basically (well it is not so basic, but is basic to use) what CurvanadeMobile Social Extension support is this:



And with the territory we also have support for

•Private profile
•Company profile
•Contacts (Add, Remove, List)
•Friends (Add, Remove, List)
•Facebook integration
•LinkedIn integration
•Twitter integration


For a programmer it will be Basic.

You create a Company and to a company you add users and you can add groups. Each group has an owner and at least one admin. Then each of Company, User and groups can have document and photo folders that you can share if you like with others. Built in Inventions handling etc.

Data processing (upcoming)

We get a lot of questions about our data processing so here comes a short description of the Magic:

At present we publicly provide data storage and search based on the reference data concept. We have however in the platform already, compute functionality allowing custom data processing as well as storage in a scalable way to be implemented as Code objects (CurvanadeMobile supports both CLR and DLR) without the need to deploy or compile assemblies.

The data processing is done as list->list of k/v pairs, more referred to as "vectors".


Execution concept

CurvanadeMobile handles both data and custom code execution the same way – by subdividing and distributing the data and/or code to execute based on key-space shards and available clusters and instances within the clusters. Preferably deployments counts per level are prime numbers in order to create appropriate redundancy and failover coverage in the scenario that key-space division is done according to the following simple rule. Key space here is defined as partition-key.

1. Primary key space division is a straight forward division by n so that the key spaces are evenly distributed over n nodes i.e. kinstance=(ktot / n)
2. Failover key space division is done by kfailover=(ktot/(n-1))+ Ktot/(n)

GRID mode


Cluster mode (single cluster)




The processing is done (for each cluster/node) as follows:


Vector Read(keyspace): Reads the designated data to form the initial vector
OutputVector Map(input vector) : Does the actual logic
Partition: Determines reducer to send results to
OutputVector Reduce(input vector 1, input vector2): Does combination of the input vectors
Write (result vector): Persists the actual result


Who do we compete with?

We have been working on this since 2008 and have more than 15 000 developer hours on this. We now see some competitors like, and However in the long run we like to be the Mobile Hadoop and Cassandra. Now that said there is no turning back!

When do I get all this?

When will I get all this you ask yourself.

Well soon! We have started our Private BETA for CRUDIS and after that we will go to public beta for CRUDIS and in the mean time we will start a private Beta for Social Extension and  when we will go Live with CRUDIS we will go Public Beta with Social Extension and then start our Private Beta for data processing.

More Info Coming soon

Developer Guides and SDK for iOS, Android, Windows Phone 7, Windows Phone 8, Windows 8, .NET, JAVA and JavaScript