Hacker News new | past | comments | ask | show | jobs | submit login
One Database To Rule The Cloud: Salesforce Debuts Database.com (techcrunch.com)
69 points by vdondeti on Dec 7, 2010 | hide | past | favorite | 68 comments



They seem to have exactly positioned themselves in a spot that will ensure that nobody ever uses them.

Cloud databases are what you reluctantly use when you realize that your thing is going to need to scale big. Database.com is prohibitively expensive for anything but tiny datasets and low traffic. Oops.

So while it would be great for running your in-house inventory application, there's no compelling reason to migrate off your existing (possibly free) relational database infrastructure.

And while it would be be great to be able to handle tons of requests to tons of data at the low latency they quote, you can do that on AWS for 1/1000 the cost.


Salesforce targets enterprises, not startups. The users of this service will almost certainly be their existing customer base, for whom it is an add-on to existing services... not a new major platform and expense.


Great? 300 ms in response time would make it slow as dirt in many many situations.


...but perfectly acceptable in many cases.


The problem with comparing AWS to SalesForce is that SalesForces' prices are negotiable, often with very deep volume discounts. AWS pricing is completely upfront, which I prefer, but... just sayin'


Maybe it's too expensive for a cash strapped startup, but SalesForce is Enterprise with a capital E.

This product is very powerful and is going to be extremely lucrative, but won't ever be interesting to most of us hackers.


Database.com is so ugly and unprofessional looking I at first thought it was a spam site and actually had to double check the URL.


I agree 100%. Clean black and white would look way more professional. From there, add a color here and there but the theme used here is damn ugly from my point of view.

They eye of the beholder...


Do you aim to change the definition of "ugly"? The site is good-looking and totally professional with some good features. Read rest of the comments to know more :)


I can't tell if this is sarcasm. The site looks like it was designed by a versatile programmer who knows what attributes a good-looking site should have, but can't reproduce it himself.


Looks more like a site put together by a programmer who downloaded a premade HTML template.


No sarcasm here. I really want to know that as a user what is driving you off that site?


JPEG artifacts on the logo, The arrow images left to "Cloud", "Open", "Social" and "Secure" are not antialiased. The arrow in the search box is below the center of the box, and lots of other minor issues that makes it look really awful.


Kudos for having an eye for detail, and I agree on the anti-aliasing part. Much appreciated. But aesthetic details are just a subset of professionalism, its not professionalism all by itself. The site has different section for intro, pricing, faq, blog and moreover they have a well done short video explaining what Database.com is about. These details are professional enough for a user to stick.


Are they? Like the OP of this thread, my immediate impression was that I was at the wrong site. It just feels like a domain squatting site, really (especially the "database.com" in the upper left. Here in the 20xxs it just isn't that impressive that you got a dictionary word domain, so stop being so impressed with it).


Seriously? Which domain squatting site has so much of information and a video which explains it's service! Just because it's 2010, does not mean that no one can have a dictionary word domain. They probably had lot of money to spend so they got it.

I am not hugely impressed by the artwork of the site but it is definitely not the worst site that I have seen


Many spammers know how to embed a YouTube video (it uses the YouTube player...), and I'm not going to click through to the other information if I think I'm on a cybersquatter page. They presumably spent at least a mid six figure sum* on the domain back in July, which makes the amateurish landing page even more embarrasing.

It's not the worst site I've seen, but I've seen better landing pages designed as weekend projects by people who then post on here with all the appropriate "I'm not a designer...can you give me some help please" questions and get advised to commission a freelancer who knows a bit about colour schemes as well as having the time and skill to add polish. For a major launch from a massive corporation whose products are (theoretically) driven by good UI and a consistent corporate image http://www.salesforce.com/assets/pdf/misc/SFDC_StyleGuide120... it's quite shameful.

*reserve price if you wanted to buy at auction earlier in the year was $800,000


I agree, it looks like total 'programmer art'.

The flat grey at the top. The logo. The badly resized bullet points with jagged artefacts. No sign of the original salesforce logo. All the fonts are a little too big, but not in a pretty way. The pricing page.

I guess there's something to be said for simplicity, but this site looks like a Frontpage template.


It resembles some of the standard Joomla/Drupal templates.

My first thought was "probably designed using PowerPoint"!


I am not sure if an app running on a different cloud platform like (Google App Engine / Azure / etc.,) can make use of Database.com and still provide decent response time to user requests.

This service will be helpful for pre-generating reports having queries which span across multiple tables (JOINS) and which can use aggregate queries (SUM/COUNT/MAX/MIN/etc.,.), both of which are currently not possible with Google App Engine's BigTable. But with Google already working on full-featured SQL database support (http://code.google.com/appengine/business/roadmap.html), I don't think I will use it for such an use-case too.


right, i agree, it would be good for schemas that require heavy database processing.


I've noticed something interesting about this service. They mention that they support row-level security. If they also support anything like stored procedures, you could basically allow your service to contact database.com directly from the side - no hosting- roundtrip.


I found that to be inferred elsewhere in the article as well. If true, it's a very interesting feature. Imagine being able to leave out the middleware web layer entirely and securely have direct access to data within the app!


Hmm, a move towards a pure big-phat-server:thin-client architecture? Not pretty.

"Best practice" moved away from that because our databases were struggling with stored procedures on top of their regular work.


Wouldn't that slow down an application to have every database call go over the internet?


I guess the trick is to make sure your servers are close to the database... like running on force.com ;-)

I guess for most sites, users won't really notice a few hundred milliseconds. I mean, most websites take many seconds to load when you factor in all the individual files and images, etc.

UX performance is more about perceived delay (by end-users, not us technical folk) rather than actual delay. If you want to use a product like this so you no longer have to think about your database (and are willing to pay what seem to be quite high fees), design your application to account for the fact that there will be large amounts of lag... that's what parallelisation and non-blocking IO is for.


This doesn't make any sense at all to me for generating dynamic html, since the whole page load will be stalled while you run your db queries. Most sites run many queries to generate a page, at least some of which need to be done serially, so you're adding (300ms + WAN latency) * (num serial queries) to the page load time.

If you have a pure ajax app that's directly hitting the db, then it starts to make some sense, as this isn't too much slower than it would be to hit your own service backed by a local db (though 300ms is definitely on the slow side for queries). This seems to be the use case they're aiming for given the focus on end-user authentication.


This is my question. 300 milliseconds is nice, but once you add HTTP overhead, then TLS overhead, it will be almost impossible for your site to respond to YOUR user in less than a second or two.

We'll see in 2011 I guess.


There are other cloud-based database services out there - and from my (fairly limited) experience the latency involved is rather noticeable.

It might be different if you do bulk uploads of data and then spend a lot of time querying it and retrieving relatively small reports - but that's probably not what most applications spend their time doing.


possibly, they expect you tu build most logic in store procedures so that you can minimize calls.

Also, once you cache them to avoid hitting a backend xSQL store you can also cache them to avoid hitting a remote SQL store, I imagine.


I am sure this is the number 1 concern for them. If they don't solve this then they have just screwed themselves over.

Bigger concern: How exportable is this database (my guess is very, since its a resful api to access it all) because at some point if they fail, you going to need to move to your own cluster.


Whether the API is REST is irrelevant. In most big data use-cases on real systems, you have special dump/export tools to get your data out. In this case, the question is whether such a tool/API exists, how fast and practical it is. It can be simple though, eg. do they have a button on the webconsole that exports your dataset to a CSV file that you can then download per FTP.


> "We see cloud databases as a massive market opportunity that will power the shift to real-time enterprise applications that are natively cloud, mobile and social."

Wow; that's an impressively high corporate-buzz-word-speak ratio. I guess if we take it literally, though, I guess AT&T and IBM employees have real-time, cloud-based social internal apps to look forward to (IBMVille?).


$10/month/100k records? That is outrageously expensive, even ignoring the transaction costs.


A much better summary of the service than the techcrunch article:

http://www.destinationcrm.com/Articles/CRM-News/Daily-News/S...

The enterprise security compliance can not be understated.

This is an extremely powerful service that any of us can sip on cheaply. It probably doesn't fit your use cases, but those saying it is too expensive or offers nothing over other database software or services are missing the point.


If you're curious how SalesForce is pulling this off from an architectural point of view, check this video:

http://www.youtube.com/watch?v=4MZZDI18opk

It's mostly built on Oracle RAC.


Oracle RAC? That explains why it's so expensive.


and the entire premise of the first paragraph of the article is flawed:

"""Oracle has dominated the database market, especially following its $7.4 billion acquisition of Sun Microsystems. But today, its “frenemy” Salesforce.com will become more of a competitor with the launch of Database.com, the company’s enterprise database built for the cloud."""


Would it kill them to spend two minutes checking for spelling mistakes / typos?

Poor reporting aside, I think this product is... no, I don't know, because the article gave no concrete information at all. Except of course that it's in the cloud!


I kept wanting to pull out a red pen while reading the article. Ack, I'm not even that obsessive about grammar.


They didn't even provide a link to database.com.


We just released (as in literally 5 hours ago) a competitor to database.com called ClearDB. Our solution is much simpler than theirs is and is priced much more attractively (starter accounts get 400K calls per month for free). We're actually looking for folks to check it out and give feedback. Would you folks mind having a look around? Check it out - www.cleardb.com.


How will you handle varying security levels? I don't want to put my principle username and password into an app that I distribute that can literally do anything to my databases. Can you or will you be able to have multiple users/access levels per account?


That's something that's definitely in the pipeline.


While having a database online is a cool thing, they need to start offering basic hosting to make this really kick off.

Roundtrips will be the major bottleneck, so the solution would be to never leave the server. So, hosting apps like AppEngine is the only way.

Or, just offer online databases but with an access-like interface (plenty of potential use cases here) so people store and use the data right there, possibly offering a great reporting tool (like what Crystal used to be eons ago) with a casual REST request for external reports and stuff, but never for external intensive use.


https://www.salesforce.com/platform/ may service that need, but I'm not entirely sure of the capabilities of the platform w/r to web apps.


Lot of Salesforce haters here. A couple of counterpoints to reactions:

-Remember that Salesforce is targeting large enterprise deals. Sure they want to be developer friendly, but "in the cloud" is overused because there are so many legacy on-premise SAP/Oracle/etc systems.

-The costs should not be compared to AWS, but instead to AWS + the cost of a developer headcount. One of Salesforce's goals it seems is to make it so once implemented minor changes to structure and process are able to be done by business users.


I was just checking out force.com and left pretty quickly after discovering they want $50 / user per month. Makes it pretty hard to make money that way.


Makes it pretty hard to make money that way.

You say that as if it's hypothetical...but actually their numbers are great. http://www.wikinvest.com/wiki/Crm

$50/month means it pays for itself if you save that user ~1 hour in that month (ie less than 1% productivity increase.)

If you take a cab from A to B, it costs way more than driving yourself, but you don't have to own a car or know how to drive.


Sorry, let me clarify. It makes it hard for me to make money using their platform if I have to pay them $50 / user / month.

Clearly it's very profitable for Salesforce.


For what it's worth, LucidDB ( http://luciddb.org/ ) has a Salesforce foreign data wrapper for it. ( http://pub.eigenbase.org/wiki/FarragoMedSalesforcePlugin ) LucidDB's a column-store standards-focused SQL database, which makes it a lot faster for certain operations (and slower for others, like single row inserts).


My pet peeve with Salesforce is that getting to the data can be difficult especially from other systems.


I think it is geared more towards mobile apps, which rely on remote db calls anyway.


correct me if i'm wrong, but this is something to use in conjunction with existing cloud applications right? thanks techcrunch for another non-informative article.

i imagine this wouldn't be something someone would consider to replace their in-datacenter database solution, going over the WAN to access database data would be awful.

i see this more as a service you would consider rolling up if you were already using vmforce to add automatic database capabilities that could scale according to demand.

anyone else have thoughts on this?

i wonder if they provide any partitioning automatically built in, that would be cool.


A number of users mentioned removing middleware from their applications and using this db directly.

Out of curiosity, how would one hide the db structure and secure it from malicious users in a javascript app?


I'm have competing technology that does this. First, you have to set permissions carefully, of course. Then, if you don't mind users knowing elements of your schema, you can simply make direct calls from Javascript. If you do mind, you could create stored procedures. Or in the case of our technology, you can also place server-side Javascript on the database and call that.


Interesting. So one would have to use the db permissions for each user instead of one db user approach of modern web apps.

I guess all of the Man in Middle security considerations would still apply.

Does you service/users use triggers as security as well?


It can be role based, so you could still have one role for all users, such as view and insert only for a forum. But our solution has an interesting twist: security is managed like queries. For example, taking a sports social network, a team's messages can be sent [an insert] by team members, but seen [view rights] by members of the team and their friends. This is all set with two statements.

It makes it so that you can go more often just directly to the database.


I signed up. Figured why not try it out. I really like outsourcing as much as I can (platform as a service like AppEngine and Heroku, datastores like MongoHQ and Cloudant, etc.)


The obvious comparison seems like it would be with Amazon RDS


I think a better comparison would be Amazon Simple DB in terms of its use of the cloud, but amazon RDS in terms of its relational model.


SQL over a web service...speedy !


.Net, Java, Ruby and PHP but no direct Python support?


"and more."

I think they just copy/pasted a press release.


No. I think with the purchase of Heroku it's clear they are betting big on Ruby.

I hope this is good for the Ruby community. It could go either way.


300 ms response time doesn't seem so good.


Can this be compared to fathom db? http://fathomdb.com/about/home

Do we have anyone with experience with FDB on hn?


FathomDB is much closer to Amazon RDS - MySQL-as-a-service. Every customer gets their own MySQL instance, and accesses it over the MySQL protocol, using normal SQL (the MySQL flavor at least). Database.com looks to be Salesforce repackaging their wrapper which lets them do multitenancy in Oracle. You'll be stuck with what the wrapper exposes, which isn't very SQL like, and certainly won't be a drop-in replacement for any existing SQL applications. They aren't offering Oracle-as-a-service.

In terms of latency, Amazon RDS and FathomDB both target applications running on the same cloud as the database. I would imagine that would be the sweet spot for database.com as well, but there are some applications where the Internet latency could be tolerable.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: