MySQL vs PostgreSQL
By: Mike Wolfe
Tags: MySQL, Data Science, Dbms, Postgresql, Database

MySQL vs PostgreSQL

Photo by Nicole Mason on Unsplash

A little bit ago I compared MySQL to SQLite. It was both something I enjoyed writing and something I found interesting. I wanted to carry forward this and use it as a deeper dive into other Database Management Systems. I decided to learn more about Postgres and thought the comparison would help to clear up areas of confusion if any were to be found. Also, by comparing there seems to be a deeper dive into aspects other than just the syntax.

Let’s start looking at what Postgres is and how it differs from MySQL without any further delay.

What Is PostgreSQL?

PostgreSQL also referred to as Postgres, is an object-relational database management system that is both free and open-source. It can run on all major operating systems and is ACID (atomicity, consistency, isolation, durability) compliant. Postgres not only comes with a wide variety of features but also has flexibility for customization. The syntax is also easier to learn and beginner-friendly.

Now that we have a brief background on Postgres, let’s look at the difference between MySQL and Postgres.

RDBMS vs ORDBMS

MySQL is a Relational Database Management System (RDBMS) while Postgres is an Object-Relational Database Management System (ORDBMS). In a Relational Database Management System, the database is based on the relational model. This means that all tables have at least one relation to another table, and none exist without a relation. An Object-Relational Database Management System has qualities of both an RDBMS and of the Object-Oriented Relational Database Management System. This means that not only are the tables related and linked, but there are also elements of Object-Oriented management systems, which means that it supports features such as objects, classes, and inheritance.

Data Types

Along with traditional data types, MySQL supports types such as Strings, Characters, Date and Time, Decimals, Large Text, Booleans, and even BLOB types. BLOB is a type that may store binary data. On the other hand, Postgres supports every data type listed above and then some. It can store Enumerated types, Unstructured types such as JSON or XML, Geometric types, and even Network types. There is also support for spatial data types.

Database Capabilities

When considering the GUI that will be used for each, MySQL has MySQL Workbench. For Postgres, you would use PgAdmin. Postgres also uses a single storage engine, while MySQL has multiple. MySQL is seen as more of a product, whereas Postgres is more of a project.

In terms of the SQL capabilities, there are a few differences. Once such difference occurs with temporary tables. Although both may create temporary tables with a “CREATE TEMPORARY TABLE”, only MySQL has the keyword TEMPORARY in the DROP statement. This means that you must be more careful with your naming conventions, as a temp table may have the same name as a regular table, and because you don’t specify the “temp” in the DROP statement, you could unintentionally lose data.

When it comes to dropping or truncating tables, there is a major difference as well. With Postgres, a dropped table supports the CASCADE option. This means it will also drop anything dependent on that table. MySQL does not support CASCADE. Similarly, with truncating tables MySQL does not support any CASCADE options. With Postgres, truncating allows for CASCADE, RESTART IDENTITY to put the ID back at the starting value as if previous data never existed, or CONTINUE IDENTITY which would be more like what MySQL does with the ID remaining in the same place even though the data is gone. For IDENTITY, Postgres supports an IDENTITY, while in MySQL the equivalent would be an AUTO_INCREMENT integer.

For Stored Procedures, MySQL requires that the procedure is written in the SQL syntax. In Postgres, the Procedures are based on functions, which can be written in other languages, such as SQL, Python, Perl, JavaScript, or others.

With Indexes, only Postgres offers different types, such as partial indexes or even Bitmap indexes. Triggers are also more flexible to a wider variety of abilities in Postgres than with MySQL. Partitioning, however, is more limited in Postgres, allowing only a RANGE or LIST. In MySQL, partitioning has RANGE, LIST, HASH, KEY, and even composite partitioning options.

MySQL is not case sensitive, but Postgres is. This means that queries could fail if not cased appropriately. In addition, MySQL allows for IF and IFNULL statements, while Postgres does not. Instead, a CASE statement should be used.

Scalability

When new connections are added, each connection with MySQL is a thread, while a connection in Postgres is a process. When it comes to concurrency, Postgres uses Multi-version Concurrency Control (MVCC). This is made to support multiple users with less of a chance to lock. This is because of the parallel query plans it implements.

Because of the additional processes for each connection in Postgres, there is a small amount of memory (approximately 10 MB) required for each. However, Postgres does not limit the database size, making it a good choice for large database management. As far as complexity, Postgres is also more complex as it allows functions, inheritance, and so on. MySQL is focused on speed and reliability.

One interesting note is that for other differences, the gap is closing. A lot of this is due to user needs being addressed by both Postgres and MySQL in recent updates. These updates are proving themselves to be more expected as a standard for user requirements. Because of these updates, the databases do have similarities as opposed to only differences. This makes the decision between which to use just a little bit harder. Or maybe what it shows is that both databases are committed to fixing standing issues, meeting needs, and ultimately both very decent choices for your projects.

Conclusion

If you’re looking for an easy, fast, and popular database that will be reliable and easy to understand, MySQL may be the better option. But if you’re looking for a much larger database or more features and complexity, PostgreSQL may be the better choice. Maybe your decision boils down to support, where you need the database with better help. Or maybe your decision is based on more standards or work expectations. Regardless, both database management systems seem to be a fair choice.

For your projects, as I’ve said a hundred times, it really is up to you. You can pick any technology you need to suit your own needs, and my opinions may not line up with the goals for your projects in the same way they do for mine. In either choice, you know your project better than anyone else, so try to take what you know about both to decide instead of simply knowing the decisions of others.

In all regards, I hope you found this analysis helpful for your decision-making. Both database management systems seemed to have benefits as well as drawbacks, so hopefully, you have learned enough to pick whether you would use MySQL or PostgreSQL, or even to have been encouraged to go learn more about both. Until next time, cheers!

Read all my articles for free with my weekly newsletter, thanks!

Want to read all articles on Medium? Become a Medium member today!