One Database To Rule The Cloud: Salesforce Debuts Database.com
techcrunch.com
techcrunch.com
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.
This product is very powerful and is going to be extremely lucrative, but won't ever be interesting to most of us hackers.
They eye of the beholder...
I am not hugely impressed by the artwork of the site but it is definitely not the worst site that I have seen
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
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.
My first thought was "probably designed using PowerPoint"!
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.
"Best practice" moved away from that because our databases were struggling with stored procedures on top of their regular work.
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.
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.
We'll see in 2011 I guess.
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.
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.
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.
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?).
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.
http://www.youtube.com/watch?v=4MZZDI18opk
It's mostly built on Oracle RAC.
"""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."""
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!
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.
-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.
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.
Clearly it's very profitable for Salesforce.
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.
Out of curiosity, how would one hide the db structure and secure it from malicious users in a javascript app?
I guess all of the Man in Middle security considerations would still apply.
Does you service/users use triggers as security as well?
It makes it so that you can go more often just directly to the database.
I think they just copy/pasted a press release.
I hope this is good for the Ruby community. It could go either way.
Do we have anyone with experience with FDB on hn?
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.