Salesforce.com Abandoning Its Postgres Flirtation?

As brinkmanship goes, few can compete with Salesforce.com CEO Marc Benioff or Oracle CEO Larry Ellison. While the world oohed and aahed over the dynamic duo's nine-year partnership announced last week, missing from virtually all reports was Salesforce.com's dalliance with PostgreSQL, the increasingly popular open-source relational database.

Was Salesforce serious about Postegres? Or was it simply a way of building leverage?

Salesforce Flirts With PostgreSQL

Last year Salesforce, a long-time Oracle customer, sent ripples through Oracle's Redwood Shores campus when job postings revealed that the company was hiring five Postgres developers, with the possibility of hiring as many as 50 in 2013. Those ripples became waves when Salesforce recently hired Tom Lane, a prominent Postgres developer.

PostgreSQL, or Postgres as it is often referred, is an open source relational database that competes with Oracle's own database, as well as the MySQL open source database that Oracle picked up when it acquired Sun Microsystems. 

Separate from these public moves, I've heard from several inside sources that Salesforce was, in fact, weighing the feasibility of a serious jump into Postgres as a way to break its dependence on Oracle. 

Now that the two companies have made long-term plans together worth at least $10 million for Oracle, however, some Postgres developers like Bruce Momjian now believe that Salesforce is dumping its interest in Postgres, and may simply have seen the open-source database as a pawn to be played in its larger negotiation with Oracle. While the Postgres community's Josh Berkus was quick to disavow such suggestions as mere speculation, they have more than a ring of truth.

All of which suggests that Salesforce never really thought about leaving Oracle behind. As one analyst friend noted to me, "The reality is that it's very hard to migrate 14 years' worth of customizations. Salesforce had no choice. The whole Postgres idea was nice in theory but not reality. It's simply too hard to port."

Salesforce's Pyhrric Negotiation Victory?

Sadly for Salesforce, the company may have painted itself into a corner, even if it did manage to chop a few million off Oracle's price tag. Make no mistake: Oracle's database technology is excellent. The problem is that it's also legacy, and is ill-equipped to embrace the industry's transition to Big Data.

As Cowen & Co. analyst Peter Goldmacher stresses, "Oracle ... is far too rigid if Salesforce is really going to take advantage of the enormous amount of data it has. It's not just the standard reporting/analytics they have to partner for, but it's also the missed opportunities/flexibility to leverage all that data in so many ways."

Workday, ostensibly the loser in this Salesforce+Oracle pile-up, is built on open-source infrastructure and as such is much better positioned for the future, a theme echoed by GigaOm's Derrick Harris.

Same Ol' Same Ol' At Salesforce

Postgres wouldn't have solved Salesforce's Big Data requirements, but it would have given Salesforce more sovereignty over its infrastructure. Before Salesforce crowed about running commodity servers. Now it's paying up for Oracle's Exadata servers. Good luck trying to get off those, or to scale them out.

But it was probably too much to expect Benioff, a protegé of Ellison, to diverge too far from his Oracle background. He now declares that choosing Oracle was the best decision he has ever made. Perhaps it was. But it will be interesting to see how he feels about this even three years from now, when data infrastructure has changed dramatically and he's still mired in legacy architecture. It's amazing how fast the database industry has changed in the past three years, with NoSQL and Hadoop on the rise as ReadWrite's Brian Proffitt highlights.

This will simply continue, and Salesforce has just paid to remove itself from some of the biggest innovations the tech industry has seen in 30 years. All of them open source. None of them invented at Oracle.

 

Image courtesy of Magnus Manske under the Creative Commons Attribution-Share Alike 2.0 Generic license.