MySQL Alternatives to MySQL(techportal.ibuildings.com)
techportal.ibuildings.com
MySQL Alternatives to MySQL
http://techportal.ibuildings.com/2012/03/15/mysql-alternatives-to-mysql/
10 comments
Here's a cached version: http://www.postgresql.org/
asking seriously, are there any downsides to using postgresql?
The out-of-the-box configuration for Postgres has a lot of performance issues compared to MySQL. I'm not really sure what scenario it's designed for, but I've always needed to make changes for my use case.
Postgres' query optimizer is a lot smarter than MySQL's. For trivial queries this is irrelevant, but your queries have to get a lot more complicated before they'll confuse Postgres relative to MySQL.
Postgres doesn't (that I know of) have multiple storage engines. You don't get something like MyISAM where you can trade transactional safety for better read performance. This is both a plus and a minus: you only have one option but all of the storage engine-related developer time has gone into fixing up that one option.
If you're experienced with MySQL, Postgres will probably come off as ... pedantic. Historically it as a project has cared a lot more about data integrity than MySQL has. That means a lot of the things you could "get away with" in MySQL aren't allowed. In general this is a good thing, but it also can get irritating.
In general, Postgres seems to expect you to know/care a lot more about databases. MySQL is set up so that many use cases work well enough without tuning it, but the flipside of that situation is that the average community member probably doesn't know as much about configuring it to get better performance.
If you're looking to treat your database as a big heap that stores your data and more or less efficiently regurgitates it (i.e. 90% of web programming's use of databases) then Postgres is likely going to need too much babying for the value it provides. If you actually need to deal with very complex queries and can afford to care deeply about your data, I'd have a hard time recommending anything else.
Postgres' query optimizer is a lot smarter than MySQL's. For trivial queries this is irrelevant, but your queries have to get a lot more complicated before they'll confuse Postgres relative to MySQL.
Postgres doesn't (that I know of) have multiple storage engines. You don't get something like MyISAM where you can trade transactional safety for better read performance. This is both a plus and a minus: you only have one option but all of the storage engine-related developer time has gone into fixing up that one option.
If you're experienced with MySQL, Postgres will probably come off as ... pedantic. Historically it as a project has cared a lot more about data integrity than MySQL has. That means a lot of the things you could "get away with" in MySQL aren't allowed. In general this is a good thing, but it also can get irritating.
In general, Postgres seems to expect you to know/care a lot more about databases. MySQL is set up so that many use cases work well enough without tuning it, but the flipside of that situation is that the average community member probably doesn't know as much about configuring it to get better performance.
If you're looking to treat your database as a big heap that stores your data and more or less efficiently regurgitates it (i.e. 90% of web programming's use of databases) then Postgres is likely going to need too much babying for the value it provides. If you actually need to deal with very complex queries and can afford to care deeply about your data, I'd have a hard time recommending anything else.
If you're looking to use it with OSS projects there's still a big MySQL bias. If you plan on using it like MySQL, you'll quickly run into casting problems because Postgres is much stricter with types, which is good. Basically, all the downsides are actually upsides.
Here is one MySQL user's naive response.
Generally speaking, postgresql is not as performant for short queries as MySQL. The MySQL community size is larger than postgresql, although postgres has a substantial community.
Generally speaking, postgresql is not as performant for short queries as MySQL. The MySQL community size is larger than postgresql, although postgres has a substantial community.
I've been working with postgresql for the last 8 months. I dont really like it though I've gotten used to it now. One thing that sucks in pgsql is the DB-link package. I feel MS SQL Server DBLINKs are way better.
I cut my DB teeth on Oracle and mysql, and have worked with MS SQL server for about 2 years before we moved to postgresql, so I may have a bias but I have to say I'm not terribly impressed with it. One nice thing I found a few months ago was the acquire lock functions in pl/pgsql. This was useful at the time.
I cut my DB teeth on Oracle and mysql, and have worked with MS SQL server for about 2 years before we moved to postgresql, so I may have a bias but I have to say I'm not terribly impressed with it. One nice thing I found a few months ago was the acquire lock functions in pl/pgsql. This was useful at the time.
by default, text comparisons are case-sensitive - the opposite of mysql. you'll need to enable some 'citext' extension (or come up with some other workaround).
There's other diffs, but that's one of the ones that jumps out.
Other downsides in what respect? Performance? Compatibility? Portability? Until a few years ago, mysql on windows was better supported, but I think pg on windows has closed that gap a lot (haven't used it on windows anything beyond a basic install, so can't comment too much).
There's other diffs, but that's one of the ones that jumps out.
Other downsides in what respect? Performance? Compatibility? Portability? Until a few years ago, mysql on windows was better supported, but I think pg on windows has closed that gap a lot (haven't used it on windows anything beyond a basic install, so can't comment too much).
Something I found while working on my dissertation (that's already known) is that performance is pretty poor for aggregate functions (MAX, MIN, AVG) - wish I'd known that before as I use a lot of them!
On a similarly sized dataset (although I'm yet to test on the same data) MySQL performed a lot better.
On a similarly sized dataset (although I'm yet to test on the same data) MySQL performed a lot better.
I have heard of performance differences and memory requirements being lower for MySQL but at the end of the day it doesn't matter much.
This was such the obvious, vim vs. emacs, automatic and expected response... and yet I still laughed. Well played, sir.
I've personally used Percona/XtraDB quite a bit - if you are used to MySQL it is pretty much a drop-in replacement (i.e. you won't need to rewrite any queries). One nice feature is the ability to do hot backups without locking tables, using their XtraBackup:
http://www.percona.com/software/percona-xtrabackup/
http://www.percona.com/software/percona-xtrabackup/
TechZing recently had a really great interview with Baron Scwartz from Percona. A really interesting interview, highly recommended:
http://techzinglive.com/page/975/172-tz-interview-baron-schw...
http://techzinglive.com/page/975/172-tz-interview-baron-schw...
"Error establishing a database connection". Better find an alternative quick :).
oh the irony
Article loaded fine for me.
It's a pretty good overview of the differences between percona, mariadb and drizzle, with more on what the focus of each project is, as well as the pros and cons. Probably nothing many of you didn't know at some level, but nicely collected in one spot without any major prejudicial comments.
It's a pretty good overview of the differences between percona, mariadb and drizzle, with more on what the focus of each project is, as well as the pros and cons. Probably nothing many of you didn't know at some level, but nicely collected in one spot without any major prejudicial comments.
That's funny. I just assumed that it was an attempt at a joke since it gave a DB connection error.
Just my experience, but there are a whole bunch of optimizations one can make to "official" recent MySQL versions before having to switch platforms, even to mostly compatible ones as mentioned in the post. Yes, Oracle ownership can be a reason to switch, but if you don't want to, don't just assume the thing can't scale til you hit the point of "more hassle than it's worth". Premature optimization and all that.
This article fails to mention the licensing problems that caused issues with MySQL, only that it was "a change in ownership". PostgreSQL has they kind of license you want to go with ... a large part of it's historical and future strength(s).
To summarize: Don't use non-permissively-licensed database software, otherwise you're screwing yourself down the road.
To summarize: Don't use non-permissively-licensed database software, otherwise you're screwing yourself down the road.
"Error establishing a database connection"
Bad advertizing joke this one.
Have anyone tried drizzle? It looks like its developers are trying to bring some of the postgres goals to MySQL codebase. I wonder if anyone has seriously used the software?
devNullDB
NoDB