Friday, December 10, 2010

Preliminary Cost Comparison of Database.com and SQL Azure Databases for 3 to 500 Users

Update 12/10/2010: Added my reply to Igor Tsyganskiy, made minor edit to second comparison, and linked to SkyDrive copy of second edition.

Update 12/9/2010: Database.com General Manager Igor Tsyganskiy contended that my  “pricing model is wrong and looks very inflated” in a comment to Tim Anderson’s Database.com extends the salesforce.com platform post. I’ve added an alternative cost model to the end of this post.

Update 12/8/2010: Tim Anderson (@timanderson) updated his Database.com extends the salesforce.com platform on 12/8/2010 to include details of “a chat with Database.com General Manager Igor Tsyganskiy.” See bottom of this post.

Salesforce.com announced their Database.com cloud database on 12/6/2010 at their Dreamforce 2010 conference at San Francisco’s Moscone Center. My initial review of Database.com’s specifications and pricing indicate to me that its current per-user/per-row storage and transaction charges aren’t competitive with alternative cloud database managers (CDBMs), such as SQL Azure or Amazon RDS. Here’s a capture of Database.com’s Pricing page:

 image

Database.com’s FAQ defines a transaction as “an API call to the database,” which infers that multiple records (rows) can be returned by a single transaction.

Following is screen capture of a simple worksheet that compares the cost of Database.com and SQL Azure for 3, 10, 100 and 500 users who each store 100,000 records and execute 150,000 transaction per month with the Assumptions shown:

image

The current comparison tops out at 500 users because the corresponding SQL Azure database size is 50 GB, the maximum size at present.

Wayne Walter Berry’s The Real Cost of Indexes post of 8/19/2010 to the SQL Server Team blog provides the basic steps to estimate the size of SQL Azure indexes.

You can download DbComVsSQLAzureCostPrelim.xlsx from my Windows Live Skydrive account or open it as an Excel Web App if you want to try different combinations.

If you detect an error in the comparison worksheet or differ with my approach, please leave a comment or suggestion.


Update 12/8/2010: Tim Anderson (@timanderson) updated his Database.com extends the salesforce.com platform on 12/8/2010 to include details of “a chat with Database.com General Manager Igor Tsyganskiy”:

image I had a chat with Database.com General Manager Igor Tsyganskiy. He says Microsoft’s SQL Azure is the closest competitor to Database.com but argues that because Salesforce.com is extending its platform in an organic way it will do a better job than Microsoft which has built a cloud platform from scratch. We did not address the pricing comparison directly, but Tsyganskiy says that existing Force.com customers always have the option to “talk to their Account Executive” so there could be flexibility.

Since Database.com is in one sense the same as Force.com, the API is similar. The underlying query language is SOQL – the Salesforce Object Query Language which is based on SQL SELECT though with limitations. The language for stored procedures and triggers is Apex. SQL drivers from Progress Software are intended to address the demand for SQL access.

I mentioned that Microsoft came under pressure to replace its web services API for SQL Server Data Services with full SQL – might Database.com face similar pressure? We’ll see, said Tsyganskiy. The case is not entirely parallel. SQL Server is a cloud implementation of an existing SQL database with which developers are familiar. Database.com on the other hand abstracts the underlying data store – although Salesforce.com is an Oracle customer, Tsyganskiy said that the platform stores data in a variety of ways so should not be thought of as a wrapper for an Oracle database server.

Although Database.com is designed to be used from anywhere, I’d guess that Java running on VMForce with JPA, and following today’s announcement Heroku apps also hosted by Salesforce.com, will be the most common scenarios for complex applications.


Update 12/9/2010: Database.com General Manager Igor Tsyganskiy added the following comment to Tim Anderson’s Database.com extends the salesforce.com platform post:

Tim,

Roger Jenning’s pricing model is wrong and looks very inflated. He assumed every time you bought a user you also had to buy storage and transactions for that user. The pricing we published is a-la-carte. You can only keep three free users and just buy transactions or just buy storage. Or one can add users but not add either storage or transactions. There will also be a notion of the “light user” — authentication only and cost of buying those will be way less then a dime per “light user”. Light users are usually company’s customer’s or doctor’s patients.

Update 12/10/2010: I replied:

@Igor,

I understand that pricing is ala carte, but adding users implies to me that new users will generate transactions to read records and, presumably, also add records to the database. I would expect new users to be more active than the user population as a whole.

There was no mention of the notion of a “light user,” which I assume to have only read-only access, in the Database.com documentation I’ve read to date. SQL Azure “light users” would incur US$0.10/GB data egress charges only.

I’ve just published the start of a “Preliminary Comparison of Database.com and SQL Azure Features and Capabilities” at http://oakleafblog.blogspot.com/2010/12/preliminary-comparison-of-databasecom.html. You might want to comment on that.

Database.com provides 3 free users with 100,000 free records and 150,000 free transactions, so a reasonable assumption is that typical users could be expected to consume 1/3 of these total resource quantities during an evaluation period.

Steve Fisher’s Introducing Database.com post of 12/6/2010 states:

    • Last quarter there were 25B transactions against our cloud database.
    • Last year there were 10B records in our cloud database. … This year it’s 20B.

The The Multitenant Architecture of Database.com states:

Database.com is the most proven, reliable, and secure cloud database offering today that serves 2 million users:

  • 20 billion records / 2 million users =  10,000 records per user.
  • 25 billion transactions / 2 million users / quarter = 12,500 / 3 = 4,167 transactions/user/month

New users are likely to be at least twice as active as average Salesforce.com users because of initial ETL (Extract, Transform, Load) operations, more participatory apps and newly added social networking features. This results in an estimated 20,000 records/user and 8,333 transactions/user/month, which populate this alternative comparison:

image  

Giving the benefit of the doubt to Database.com, the above still looks to me like more than a 50:1 cost advantage for SQL Azure in the range of 100 to 500 users. You can open a SkyDrive copy of the second comparison here.

2 comments:

Anonymous said...

If it's not a true SQL database / doesn't support full SQL syntax or SQL type connections it's more like Azure Table storage in which cases the prices are even more orders of magnitude more expensive.

Adrian Cockcroft said...

database.com 15,000 transactions/1$. #AWS #SimpleDB 14c/CPU-hour = 7 CPUhrs/1$, @10ms CPU/transaction = 2.5 million transactions/1$

SimpleDB is the "other" multi-tenant hosted database that has a restricted SQL query syntax.

So I agree that database.com looks about 100x too expensive to be competitive for more than trivial work.

What is good about both SimpleDB and database.com is that you can get started as a developer for no money down, and the lack of friction is one of the key differentiators for public cloud that makes it subversive in a corporate environment.

The problem with database.com is that it doesn't scale. I think the pricing is set very high to prevent people from sending them too much traffic, because it would blow up. Their stated throughput per quarter or per year is only a few thousand transactions per second, which is trivial. A single AWS account with 100 SimpleDB domains is on about the same scale as all of database.com as far as I can tell.