I just remember reading that the .org TLD was running on Postgres ten plus years ago. Yahoo knows a thing or two about scaling up on Postgres as well, as I recall. When these decisions were made, it was generally expected that one would have quite a lot of work to do, regardless.
I especially appreciate PostgreSQL's documentation. I find it easy to locate, search, and understand. I certainly have not had that experience with Oracle docs.
Oracle's documentation is excellent and is WAY more comprehensive than PostgreSQL. For example, most of PostgreSQL's SQL functions have a single line in a table to describe them, whereas each one in Oracle has it's own section with a full description, examples, etc.
I agree that the relative small size of PostgreSQL documentation and the fact that it fits in a single "book" compared to the many books that comprise the Oracle documentation can make it easier to find something. But can't say I've ever seen a product with as much quality documentation as Oracle.
As a user, you want to look in "SQL Language Reference" first, followed by "Data Warehousing Guide" (found in a separate folder on the left side). As an administrator, "Concepts" is required reading followed by "Administrator's Guide".
> Oracle's documentation is excellent and is WAY more comprehensive than PostgreSQL.
I'd generally agree that Oracle's documentation is more extensive than PostgreSQL's in many respects, but Oracle's is also substantially less well organized than PostgreSQL's.
That was a bit tongue-in-cheek... Oracle makes an exceptionally solid RDBMS and deserves credit for that. It's just that it hurts every time I write VARCHAR2.
Not only as an example of "single line in a table" but also as an example where a huge volume would not add much value.
I'm struggling at this time to figure out how to produce multiple pages of boilerplate explaining "min()" that would be any more useful than the table.
On the other hand the explanation about nulls really sucks. Its important enough to put in the single line. For those too lazy to click and read, when a noob thinks he wants "SUM(bunchastuff)" what he probably wants is along the lines of using COALESCE or a homemade function that smells like COALESCE. There is a meta discussion that whenever NULLs are possible, and its more than just table definitions for example an overactive WHERE clause, then the NULLs will be a PITA. Defensive SQL coding can be tedious.
I've always found Oracle's database documentation to be reasonably good -- PostgreSQL's is better, but I'd rather be using Oracle's than Microsoft's SQL Server docs.
To be fair, Microsoft's reference material is pretty good - it's standardized, comprehensive and available for every version. You just need to know what to google to find the right page..
In many ways PostgreSQL is fairly similar to Oracle and it also supports its own version of PL/SQL. There are tools to automate migration of both schema and data. I reckon the real difficulty of such a transition is updating application code (and legacy code) to work with PostgreSQL.
This is by design because EnterpriseDB (based on Postgres) is basically intended as a replacment for Oracle. Anything commercial that uses fancy Oracle features would want to look at this because it would be easier to support.
"Migrating from Oracle to PSQL" means almost nothing (from a technical point of view)
But what were the issues? How did their schema look like then and now? Any stored procedures? Any Oracle-only features that had to be migrated? Any PSQL-only features now being used?
Having worked on this team (QA side) for 3 years, I'm "just guessing" this was a big effort. Very cool Mark Kosters and Andy Newton gave the dev team the bandwidth to do this, their plates are almost always full of new features and whatnot.
So PostgreSQL is pretty heavily involved in internet infrastructure right now.