4 ms·
A short, probably biased and not 100% precise answer would be: no, you don't need to look for a commercial RDBMS. The real answer is: always evaluate options.
by wulczer 15y ago
A short, probably biased and not 100% precise answer would be: no, you don't need to look for a commercial RDBMS.
The real answer is: always evaluate options. Make sure the solution you choose supports everything you need and that you will be able to learn how to use it or hire people who can. Without knowing what your requirements are it's impossible to say, but in the vast majority of cases, PostgreSQL will be as good as Oracle, MS SQL Server or DB2.
If your evaluation indicates that you need to pay for one of these, double and triple check it... and only if you're 100% sure that's the case, shell out for a commercial RDBMS.
- socratic 15y agoI think that's probably true, though I do wonder from a purely engineering standpoint what features Oracle/DB2/MS have at this point that PostgreSQL does not. Special index types? Query hints? Suggestions for physical layout on table creation?
- megaman821 15y agoMaterialized views and query hints are the big ones the PostgreSQL is lacking.
- simcop2387 15y agoQuery hints are not likely to happen, at least not in the way that they do in other databases. There's been a number of discussions about it and you can see some of the aftermath at http://wiki.postgresql.org/wiki/OptimizerHintsDiscussion http://wiki.postgresql.org/wiki/OptimizerHintsDiscussion As for Materialzed Views, there's some options there currently, though it looks like native support would be a lot nicer: http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized...
- Ingaz 15y agoMore advanced query plan generators in commercial DBs. On other side: 1. PostgreSQL and MySQL are catching up (for example: Table elimination) 2. You can always throw saved money in hardware. 40 thousands per core (Oracle) - is ridiculous.
- jpitz 15y ago[edited for formatting] Speaking only to the differences between PostgreSQL and SQL Server: 1. "Live" clustered indexes 2. Query Parallelism 3. A richer API for data partitioning and _arguably_ a better query optimizer for partitioned data. 9.1 sees some wonderful improvements to the optimizer in this regard and I'll be poking at those very features in the coming months. SQL Server has query hints, but I strongly agree with the PostgreSQL's team stance on them; I'm glad they avoid them. As far as special index types: If you need a specialized index type, and nobody supports it, you're dramatically, drastically, fantastically more likely to implement it/find someone to implement it in PostgreSQL than any commercial engine.