You can login if you already have an account or register by clicking the button below.
Registering is free and all you need is a username and password. We never ask you for your e-mail.
Man, it's an old, tired debate as to which is better.
For small projects, really doesn't matter. For serious projects, you're likely going to need to mod the database itself to get the featurse / performance you need.
A common jab at MySQL / MariaDb is that its SQL syntax is not 100% ANSI compliant. In the real world, it doesn't matter too much whether your SQL is 100% ANSI compliant as the one advantage would be for when you switch database providers and that almost never happens. Even when it does happen, it's likely that you had some kind of wrapper around your SQL and that wrapper will be able to gracefully handle the switch to a new database system. In day to day use, the choices made for MySQL syntax make sense and make the life of a DB admin a lot easier.
Actually, all of the tools around MySQL make it a nicer environment for administration. phpMyAdmin and the MySQL command-line tool are head and shoulders above what PostgreSQL has on offer (i.e. pgAdmin III).
ACID compliance. PostgreSQL and MySQL both offer ACID compliant databases (MySQL through its InnoDB storage engine).
There is the problem of scaling for both. Once you get past a single server, unless it's a simple master-slave set up, you're going to have to make a serious compromise. Take a look at this matrix to get an idea of how messy the landscape is here. For MySQL, there is a storage engine called NDB that's made for high-availability applications. One major downside is that the tables must be kept in memory so you will have some beefy hardware requirements. NDB seems to provide a much more sophisticated solution to PostgreSQL's.
Short story, for a small-medium website, either is going to work pretty well for you. MySQL / MariaDB tends to be more intuitive while PostgreSQL tends to be more "correct."
Here's a good example of how MySQL is easier to work with in a day-to-day situation. TL;DR While column order reallly doesn't matter too much, MySQL goes above the strict ANSI SQL to give you a waaaaay nicer way to add a column to a table where you want it. PostgreSQL is stuck with the mentality that plain ANSI syntax is the only thing they'll consider. I run into these little quirks all the time since I work with both DBs and it amazes me how fun it is to work with MySQL while PostgreSQL is such a pain.
For day-to-day maintenance, there's only one thing I've found Postgres doing better and that's listening when I tell it to shut down a run-away or locked query. Doesn't happen often, but when I need it, Postgres handles it pretty quick. been a while since I've had to do it on the MySQL db but a few years ago when it was more actively worked on, it seemed like the kill command was obeyed only sometimes.
view the rest of the comments →
[–] Drenki 0 points 2 points 2 points (+2|-0) ago
Man, it's an old, tired debate as to which is better.
For small projects, really doesn't matter. For serious projects, you're likely going to need to mod the database itself to get the featurse / performance you need.
A common jab at MySQL / MariaDb is that its SQL syntax is not 100% ANSI compliant. In the real world, it doesn't matter too much whether your SQL is 100% ANSI compliant as the one advantage would be for when you switch database providers and that almost never happens. Even when it does happen, it's likely that you had some kind of wrapper around your SQL and that wrapper will be able to gracefully handle the switch to a new database system. In day to day use, the choices made for MySQL syntax make sense and make the life of a DB admin a lot easier.
Actually, all of the tools around MySQL make it a nicer environment for administration. phpMyAdmin and the MySQL command-line tool are head and shoulders above what PostgreSQL has on offer (i.e. pgAdmin III).
ACID compliance. PostgreSQL and MySQL both offer ACID compliant databases (MySQL through its InnoDB storage engine).
There is the problem of scaling for both. Once you get past a single server, unless it's a simple master-slave set up, you're going to have to make a serious compromise. Take a look at this matrix to get an idea of how messy the landscape is here. For MySQL, there is a storage engine called NDB that's made for high-availability applications. One major downside is that the tables must be kept in memory so you will have some beefy hardware requirements. NDB seems to provide a much more sophisticated solution to PostgreSQL's.
Short story, for a small-medium website, either is going to work pretty well for you. MySQL / MariaDB tends to be more intuitive while PostgreSQL tends to be more "correct."
Here's a good example of how MySQL is easier to work with in a day-to-day situation. TL;DR While column order reallly doesn't matter too much, MySQL goes above the strict ANSI SQL to give you a waaaaay nicer way to add a column to a table where you want it. PostgreSQL is stuck with the mentality that plain ANSI syntax is the only thing they'll consider. I run into these little quirks all the time since I work with both DBs and it amazes me how fun it is to work with MySQL while PostgreSQL is such a pain.
For day-to-day maintenance, there's only one thing I've found Postgres doing better and that's listening when I tell it to shut down a run-away or locked query. Doesn't happen often, but when I need it, Postgres handles it pretty quick. been a while since I've had to do it on the MySQL db but a few years ago when it was more actively worked on, it seemed like the kill command was obeyed only sometimes.