The ongoing MySQL campaign

Posted Jan 3, 2010 2:25 UTC (Sun) by robert_s (subscriber, #42402)
In reply to: The ongoing MySQL campaign by aba
Parent article: The ongoing MySQL campaign

"People don't choose a non-free database because they "just need any database", but because they need special features which are available only there"

Hah. The most common reason for people choosing non-free databases is salesmen successfully persuading the execs that they need an "Enterprise" ($$$$$) solution.

to post comments

The (de)merits of proprietary databases

Posted Jan 3, 2010 20:59 UTC (Sun) by butlerm (subscriber, #13312) [Link] (1 responses)

Make an open source Oracle clone that performs half as well Oracle does,
while maintaining basic Oracle compatibility and the world will line up at
your doorstep. I certainly would.

The "clone" part is important - to succeed, such a database should be a
drop in replacement for Oracle for most applications. Incompatibility with
Oracle's quirky null handling is the number one obstacle to moving
practically any good sized application from Oracle to PostgreSQL.
Compatibility with common little functions like DECODE() is another, and
support for Oracle's *much* superior outer join syntax. Lots of other
minor things, up to and including PL/SQL compatibility.

Now Oracle's dialect may not be the be all and end all of all things, but
what good does it do to have multiple competing SQL databases when each one
implements a completely different dialect with dozens of severe semantic
differences, such that you have to marry your database platform for life,
warts, deficiencies, evil licensing overlords and all?

The fastest way to *beat* Oracle is to be compatible with Oracle.

The (de)merits of proprietary databases

Posted Jan 4, 2010 6:32 UTC (Mon) by ringerc (subscriber, #3071) [Link]

Standards. Aren't they great?

I agree there are a few places where Oracle's dialect is better than the SQL standard - 'CONNECT BY' comes to mind. The SQL standard is hardly an example of great design, and is full of bizarre warts.

In most cases, though, I find Oracle's dialect painful, and its differences seem like a mix of unnecessary historical anachronisms and deliberate customer lock-in. I'm not a big fan of its left outer join syntax - it's succinct, but that's about all it has going for it. DECODE doesn't appeal when compared to CASE. Many of its odd little functions are alternatives to standard ones with different names and/or parameters that don't seem in any way better.

Of course, many developers code to the Oracle dialect anyway, because they're used to it, they prefer it, or Oracle doesn't support the standard way of doing a particular thing. So I agree that in practice it's a big adoption barrier, much as supporting all those little MySQL quirks (AUTO_INCREMENT, REPLACE upsert statement, etc) would help. On the other hand, anyone who tries to keep on using their new database as if it's just the same as their old one will be doomed to poor performance and continual irritation. Such compatibility wrappers are really just porting aids.

EnterpriseDB tries to maintain Oracle compatibility. I have no idea how well they succeed, and would be interested in your comments. For performance, while Oracle is indeed rather impressive in many cases, you can get a lot out of Pg with the hardware you can afford from your Oracle license savings. Its lack of multi-master replication is its main scaling issue these days.

The ongoing MySQL campaign

Posted Jan 4, 2010 6:37 UTC (Mon) by ringerc (subscriber, #3071) [Link] (3 responses)

... or to find out that you need reliable, trustworthy and fast multi-master clustering to satisfy your load and uptime needs.

Right now, MySQL fails on "reliable" and "trustworthy" for its MM clustering, and PostgreSQL doesn't have it at all. I'm not equipped to evaluate the MM clustering add-ons to Pg like Bucardo, but I'm figuring the approach hasn't been integrated into Pg core for a reason.

Sometimes you really do need things the OSS databases don't yet provide.

That said: frequently, the reasons are lack of understanding, lack of sales materials targeted at middle/upper management, a belief that having another company "standing behind" the product makes it invulnerable to failure, "having someone to sue", or the nice week-long party cruise the salesman promised the TIO if they'll sign on the dotted line.

The ongoing MySQL campaign

Posted Jan 4, 2010 7:45 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

for the postgres replication options, the reason they haven't been integrated into core isn't that they aren't good. it's that they can function without being integrated and the core developers have chosen to not give the appearance of blessing one of the options over the others.

different variations of replications have different advantages and disadvantages.

the replication that is going in requires core support, so it can't be maintained as a separate package

The ongoing MySQL campaign

Posted Jan 4, 2010 17:06 UTC (Mon) by foom (subscriber, #14868) [Link] (1 responses)

> the replication that is going in requires core support, so it can't be maintained as a separate
package

That seems like a terrible reason to bless one package and not any of the others. I hope that's not
all there is to it, and that the blessed one is, additionally, the best (overall, for most uses)
replication package for postgres.

Why is it in core?

Posted Jan 4, 2010 20:53 UTC (Mon) by mainpc (guest, #62803) [Link]

The replication solution is actually two separate non-replication features that are useful on their own, but when used together, create a solid replication solution.

PostgreSQL has been able to load point in time recovery (PITR) log files from one server onto another, creating a warm standby solution for fail-over. Recently, 8.5 gained the ability to serve read-only queries while performing recovery. This feature is called Hot Standby. In a separate feature, Streaming Replication, PostgreSQL will be able to send PITR data across a TCP stream in addition to the log files. Combining Hot Standby with Streaming Replication provides a solid master-slave replication solution, suitable for fail-over and load balancing of read-only queries.

This replication solution happens to be in core because that is the right place for Hot Standby and Streaming Replication to be. It is also a very low overhead design because it is based on log files that are created during normal operation anyway.