I agree with the above comment, though I do not think the differences are so severe. But I did want to go into the particulars of why Oracle has the best database product out there. This is from somebody who has developed a product that can run on most databases and has been deployed at 1000s of customers, some of whom have scaled up to billions of records. Here is my itemized list in order of importance (at least for the product I worked on).
1. Oracle has true row level transaction isolation. You start a transaction and you do not interfere with anybody who may be reading the rows you are updating. You also do not interfere with the updates to rows that are stored in the same "page". Databases that do not do this properly get two problems. The first is dirty reads where other transactions read rows that are temporarily in an inconsistent state with other rows (add a number to one row, subtract it from another, the other transaction sees the add but not the subtract). But the real problem is transaction deadlocks where each transaction is locking each other because they locked rows they were not supposed to. If you write code that is constantly "transactionally" grooming statistical data about the relative ranking of some row versus others, you will find it impossible to avoid these deadlocks. Only Oracle gives you true full row level (not "page level" as in SQL Server) transaction isolation. Developers in my group have written test programs specifically to prove this.
2. Oracle has sophisticated diagnostic tools that can help diagnose things such as: Why is this query running slowly? Is this data possibly corrupted? Where are my indexes stored and how well are they working? You have a lot of control over these things and that can really help scale a system from a million records to a billion records in a reliable way.
3. Ways to take advantage of multiple disks and fast independent IO to each disk. You can write your transaction log to one disk, partition data based on a particular column's value to various disks (for example if a column indicates "branch" of a company, each branch can have its own disk to store its data), write indexes to yet another disk. When you read or write, the database will read and write from these disks concurrently (really powerful on multi CPU/Core boxes). If the database determines that the query is targeting only a particular partition (for example, the query targets a particular "branch"), then it may figure out that it does not have to read data from the other disks at all. So if two such queries come in targeting different partitions, they will be doing IO to independent disks with independent hardware IO streams. I have had systems that were non functional for a customer become quite useful after applying clever tricks of this type (especially the partitioning when you have more than 20 partitions).
You may argue that most applications that are out there do not need these things. This is true, but nobody is going to make money from selling products to deployers of those applications -- they can usually get by on the free stuff (or close to free). If you need something from a database for which you are willing to pay real money, then Oracle still has some unmatched features.