Live data from Hacker News

Salesforce will hire 40-50 Postgres people

archives.postgresql.org

61–66 of 66 posts

Re: Salesforce will hire 40-50 Postgres people

#61
post #45

Earlier quoted context omitted.

what postgresql, mysql etc. provide is a relational database, i.e. a way to store table-structured data with consistency and safety guarantees and efficiently perform operations to retrieve and update rows from it. sql is simply the standard language in which relational queries are expressed.

So the language implies something about the functionality of the database. That seems obvious enough. But does it necessaruly tell you anything about the underlying structure and the performance of a database? If we drop that acronym, "SQL", and still provide a database that handles relational queries (but perhaps uses a different but equally capable language), does that matter? If yes, how much? And why?

There's plenty of database systems that either don't support SQL at all, or support it with a range of other languages.

One of SQL's remaining powers over most other options is the ability of non-expert users to construct their own ad-hoc reports. This is a big part of why Hadoop has Hive, which incorporates a very SQL-like language, and most other "big data" tools have something similar.

Re: Salesforce will hire 40-50 Postgres people

#62
post #42
post #15

With Oracle slowly transforming MySQL into a 'free-open-core, closed-outer-shell' RDBMS[1], PostgreSQL is quickly becoming the main go-to alternative for anyone who wants to avoid database vendor lock-in. Hopefully SalesForce will contribute its improvements back to the PostgreSQL community. -- [1] For example, see http://news.ycombinator.com/item?id=4400797

Oracle no longer publishing their test cases hardly constitutes "transforming MySQL into a 'free-open-sore, closed-outer-shell' RDBMS", moreover there is no evidence that folks are adopting PostgreSQL because they're afraid of MySQL vendor lock-in. If one feels they must pay from MySQL they can give their money to Oracle, Percona, or MariaDB, all of which whom will happily provide MySQL support for a fee. PostgreSQL…

You make a reasonable point in your first paragraph. There is no strong evidence of vendor lock-in in MySQL's case, though Oracle's past history makes for legitimate suspicion on the part of prospective MySQL users.

It's unfortunate that your second paragraph is either trollish or ill-informed. Sure, there is a part of group-think about Postgres' popularity in some communities, but Postgres has a number of advantages over MySQL (though I'd say MySQL has a better multi-server story). Implying this plays little part in its growing popularity is condescending.

Re: Salesforce will hire 40-50 Postgres people

#63

Earlier quoted context omitted.

Of course nothing is ever final, but publicly announcing something like this is already sort of a "fuck you" to Oracle, so I'd be surprised if they weren't a 100% sure of their plans to switch.

Though the plan might be to negotiate cheaper Oracle licenses..

Oracle won't negotiate with Salesforce -- there are too many personal traits between the CEOs.

Re: Salesforce will hire 40-50 Postgres people

#64
post #45

Earlier quoted context omitted.

what postgresql, mysql etc. provide is a relational database, i.e. a way to store table-structured data with consistency and safety guarantees and efficiently perform operations to retrieve and update rows from it. sql is simply the standard language in which relational queries are expressed.

So the language implies something about the functionality of the database. That seems obvious enough. But does it necessaruly tell you anything about the underlying structure and the performance of a database? If we drop that acronym, "SQL", and still provide a database that handles relational queries (but perhaps uses a different but equally capable language), does that matter? If yes, how much? And why?

sql is actually quite close to a natural way of expressing relations. there's a book called "sql and relational theory" by someone called chris date that goes into a lot of detail about this ("relations" is a technical term with a pretty solid mathematical basis). so you could change the syntax, but the basic ideas wouldn't change that much, assuming it was still a relational database.

the value of the different database implementations comes from how efficiently they can implement the relational model, and what optimizations they have to support particular use cases, or extensions to make supporting and maintaining them more practical. those optimizations/extensions also lead to some of the differences between what sql might be if it were "purely relational" and what is is in practice.

so dropping sql and using a different language would be more a nuisance than anything. what is important is whether the database is relational or not. and databases that are not relational have been tried - they are (misleadingly!) called "nosql databases" (they should be more accurately called "non-relational databases", of course, given the above).

Re: Salesforce will hire 40-50 Postgres people

#66
post #16

Earlier quoted context omitted.

And then Oracle will buy Salesforce... Larry did say something like that but he said that the price is too high. Here is my predictions: Salesforce is will start investing into new technologies and building cool stuff. However, that will not look good on stock price because R&D costs will skyrocket - and our "efficient" stock market does not like long term visions. The stock price will collapse. The board will panic…

Have you programmed Salesforce? It's a steaming pile of poo. SOQL is really terrible and don't even get me started on apex, it's like someone took all the worst bits of Java and made them into a programming language. It's really slow to boot, I was using it with a client last week and it was taking 10-20 seconds to load any page. I also really don't get how they're not making more money given the prices they charge.…

What is better than Salesforce in terms of APIs and performance?
Post reply on HN