Switching from MySQL to PostgreSQL

I was recently forced to switch from MySQL to PostgreSQL for a project I am working on and at first I was very reluctant to change because I had been using MySQL for years, was very familiar with it, and knew my way round the developers section of the MySQL website. However, having worked with PSQL I would now never go back to MySQL, it is simply in a lower league than PSQL!

When using a DB the differences are not all that big but when creating and admining DBs there are some differences that will throw you at first so I’ll list the ones I came across and how to get by them.

User Management

MySQL has a bizarre model of user management, the user bart from say localhost is considered a completely separate user to the user bart from any host or the user bart from a particular host. This makes managing users interesting and TBH I have always hated this aspect of MySQL. PSQL takes a simpler view, it uses the system accounts as its accounts. The user bart is the user bart no matter where he is logging in from and his password is his system password. Also, there is no root account as such on PSQL, if you access PSQL as the user who owns PSQL then you have ‘root’ powers, if you don’t you only have the powers that have been given to you by the DBA with GRANT statements.

Control of access to different databases by different users from different places is all controlled from a text file called pg_hba.conf in which you specify how PSQL should authenticate different users trying to access different DBs from different places. You have a number of choices ranging from ‘trust’ which lets any system user access the DB as any user without a password to ‘password’ which requires the user to supply a password and ‘ident’ which only allows the user to log into the DB as the user they are logged into the system as. pg_hba.conf is well commented with lots of examples so it is really easy to manage client authentication on PSQL and makes MySQL look over complicated and under-powered.

AUTO_INCREMENT

There is no AUTO_INCREMENT keyword in PSQL. This scared the crap out of me at first because I thought I had a real problem, but of course I didn’t, PSQL has a special data type for fields that need to auto increment called SERIAL. This creates an implicit sequence which adds a slight complication in that you need to grant users access to BOTH the table AND the sequence if you want them to be able to add rows to the table. The sequence always has a name with the format: &lt;table&gt;_&lt;field&gt;_seq.

ENUM

Again PSQL does not have an ENUM type which, at first, seems like a problem but you can create fields that are effectively enumerations using the CHECK keyword (and you can do MUCH MUCH more with it too!). To set up an enumeration called user_level with the possible values ‘STUDENT’, ‘MENTOR’ and ‘ADMIN’ you would use the following syntax:

user_level VARCHAR(10) DEFAULT ‘STUDENT’ NOT NULL CHECK (user_level IN (‘STUDENT’, ‘MENTOR’, ‘ADMIN’))

Transactions

PSQL has excellent transaction support and it is stable and works with things like JDBC which is more than can be said for MySQL ATM. And, to make it even better, the syntax is immensely simple!

BEGIN;

-- do work

COMMIT;

Shell

The psql shell to access PSQL is very very different to the mysql shell you access MySQL through. Basically you are just gonna have to RTFM it! Also, when you get stuck (and you will) just remember that \h gives you help and \q exits! The thing I missed most were MySQLs simple keywords SHOW and DESCRIBE, PSQL has the same functionality but just with much less memorable commands, e.g. \dt lists all the tables in the current DB.

Overall I find that PostgreSQL is a more powerful and more mature and robust piece of software than MySQL and since it is also open source I can see no reason to choose MySQL over PostgreSQL. Yes, if you have been using MySQL for years you will have a bit of a learning curve but trust me, it is well worth the bit of time and effort to do that learning!