Back in the late noughties, when MySQL was getting popular, people would often ask me why I was picking Postgres. MySQL was so popular and so fast and it had cool things like query caching (with postgres did not have). My answer was simple - postgresql was a “real database system.” I remember being shocked when I trying to use transactions and it just ignored it. Postgresql was also really good at failing gracefully under high load while MySQL had a bad habit of just stopping processing any requests and becoming unresponsive.

This was more than 15 years ago now so things may have changed with MySQL, though its acquisition by Oracle was certainly a bad sign.

Years on, and it would seem that people are better informed as to the benefits of postgresql.

I am currently working on a small game-like social experiment app and it requires persistent storage. I was intially considering firebase but the costs put me off. In the world of cloud, I didn’t think that spinning up a postgresql server was really an option - or is it?

Supabase

I ran into Supabase as a more cost-effective option and as a bonus it’s open source and based on PostgreSQL. I’ll admit that I was skeptical that it would embody the postgresql philosophy that I knew and loved. I expected another capitalistic effort at monetising open source.

I was pleasantly surprised. I am in the very early stages of using it, but so far, I love it. Not a huge fan its love of javascript, but the whole world seems to be a big fan (I am not - but then I wasn’t a fan of MySQL either ;))

I didn’t end up going further with it, but the early impression was good enough that I’d reach for it again.

We recently found this as we were trying to update every row in a table that had over eight million entries. We found in the first few tries that the update was taking over 24 hours to complete which was far too long for an update script.

Our investigation of this led us to the pgsql_tmp folder and the work_mem configuration parameter.

When the query was being executed, we checked the pgsql_tmp folder to see how was space being utilised in there. We already knew about the pgsql table from past experience. We had a server running out of disk space and rapidly. We had narrowed it down into this folder. In cancelling the query referenced by the tmp files in here, we were able to free up literally gigabytes of disk space...

We had found roughly half a gig of temporary files in here. This led us to investigate the configuration file.

The one parameter that stuck out was work_mem which was set to a default of 1mb which I guess might make sense under most circumstances but not in this one. According to the postgresql documentation

work_mem (integer)

Specifies the amount of memory to be used by internal sort operations and hash tables before switching to temporary disk files. The value is defaults to one megabyte (1MB). Note that for a complex query, several sort or hash operations might be running in parallel; each one will be allowed to use as much memory as this value specifies before it starts to put data into temporary files. Also, several running sessions could be doing such operations concurrently. So the total memory used could be many times the value of work_mem; it is necessary to keep this fact in mind when choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries.

This would tell us that the total memory usage with work_mem could be several times the value set here and setting it to half a gig would probably be a terrible idea for a heavily utilised production server. However, for the migration process when we need to update over 8,000,000 rows, it might be a good temporary fix.

After updating the work_mem to 512mb, we found that no more tmp files were created and the whole thing was done in memory.

When updating so many rows, there area a few other things to consider.

Firstly, autovacuum will likely kick in several times to vacuum the table. You'll probably want to disable this for the duration of the update statement and run a vacuum afterwards.

You can switch autovacuum back on after the update statement has completed

A few other things you want to take a look at are the

• fsync parameter (I usually have this set to off anyway since the servers are pratically fully redundant)
• checkpoint_segments: I changed this to roughly 5 times the original value (check the log to see if it says that its checkpointing too often)
• checkpoint_completion_target: I changed this to 0.9

With all of these updates, we were able to bring the total time of the update down to a few hours.

There is of course now way of figuring out how many rows had been updated already. The first step was to create a sequence

We can then use this sequence in the update statement to ensure that each row updated also increments the sequence

Once the query is running, you can open another connection to the database. To get an indication of how far it has got, you can just run the following

Bear in mind that this will also increment it by 1 but if you have millions of rows which is really the only case in which this would be useful, a few additional increments is hardly going to make a difference.

Good luck and have fun!

I have since used:

• Filemaker Pro,
• Microsoft Access,
• Microsoft SQL Server,
• MySQL,
• PostgreSQL,
• SQLite and
• HSQLDB.

I have not yet used:

• IBM DB2,
• Oracle.

Wikipedia has a list of database systems.

Having worked with this range of database systems and having done copious amounts of research into DB2, Oracle and other DB systems I have not mentioned, I like answering the age old questions. Which is the best database system?

Ah! if only it was that simple. There is no database system that is appropriate for any given requirement. But then, if you have been in the technology sector long enough, you would already know that. It's all about using the right tool for the job.

I separate these systems into two broad categories and Oracle. There are the Desktop based database systems:

• DBase
• Foxpro
• SQLite
• HSQLDB
• Filemaker Pro
• Microsoft Access
• MySQL

DBase, FoxPro, Filemaker Pro and Microsoft Access are essentially a GUI frontend that has a database backing.

Access is the best choice for this purpose under the majority of circumstances. Filemaker Pro is relevant in some. The usual reason to use DBase or FoxPro is simply that the developer is used to it. This is not a good enough reason.

I have used DBase III+ for developing an office management suite back in 1994. I have since used Filemaker Pro to develop a simple contact management database in 1998, Microsoft Access to develop a patient management system for a clinic.

SQLite, HSQLDB and MySQL are database engines that are to be utilised by popping a frontend on top; sometimes the frontend is Microsoft Access. Microsoft Access can also be used for its database engine.

Access is usually the worst choice for this except as a stopgap. There are exceptions to this. One is for a web frontend if the site is not too busy and its running on a microsoft platform. You don't have to go to the hassle of installing anything on the server. The drivers will take care of it all.

HSQLDB becomes an obvious choice for a light java based application and SQLite for any other lightweight applications.

MySQL is substantially more powerful and scales a lot better. I include it in this section because it is a server grade database system that can also work well in a desktop environment.

I have used Access for several web based systems and I have used HSQLDB for unit testing hibernate and for a quick and dirty MP3 library that linked into musicBrainz. I have used SQLite in passing to be utilised by open source products.

I have used MySQL with an Access frontend as a management suite for a website as well.

And we have the server based database systems:

• MySQL
• Microsoft SQL Server
• IBM DB2
• PostgreSQL

MySQL was used as the backed database system for the edFringe.com website. This was the perfect choice since the most important requirement was speed. Particuarly with the Query Cache and Master Slave replication, MySQL was the best choice.

SQL Server was used as the backend system for an online course for the Scottish Enterprise around 1999/2000. While MySQL would have been a good choice this, it was not of production quality at the time.

We have also used Ms SQL Server for an insurance company since all the infrastructure was based on Windows and PostgreSQL did not have a viable Windows version at the time.

We use PostgreSQL for megabus. While speed is absolutely critical, it is a ticketing system which means that transactionality is absolutely critical.

While MySQL now has transactionality with innodb, it is still nowhere near as good as the transactionality provided by PostgreSQL through MVCC (Multi-version Concurrency Control). We could have used Ms SQL Server but the cost savings are dramatic.

To summarise, each system has a specific use, specific strengths and weaknesses and which should be used is highly dependent on what it is to be used for. I am hopeful that the summary of what we have used each of these systems for us useful in determining which one is best placed to solve any specific problem :-D

We have not yet used Oracle and it was a strong contender for megabus but the serious heavyweight functionality provided by Oracle comes at a price and it is not yet a cost effective option.

We are not necessarily controversial, just that we hold a view that is usually a little different from the mainstream views. It could be said that we bring the alternative to the mainstream.

But then, so did some world governments, bringing open source software into their work places, successfully or unsuccessfully in the last few years instead of Microsoft.

Someone recently suggested that we were anti-microsoft. I don’t think that is case. Microsoft has its place in a technology infrastructure. It is simply that its position is usually overrated or misplaced. As far as desktops for technically shy users are concerned, there is really no alternative but Microsoft Windows. I can hear the Mac users scream that Macs are also an alternative. Theoretically, yes but the fact is that they are too expensive for someone to dabble with it. This is precisely the reason that Microsoft Windows dominates the desktop market.

We support and use Linux. In fact, the majority of the desktops in the office run Linux (Ubuntu as it happens) but people who have a non-technical role use Windows. They could use Linux but Windows is better suited to their role.

This is not necessarily a cost-saving decision. Sure, we have saved thousands of pounds by sticking to Linux instead of using Windows but that is a co-incidence more than anything. In some ways, it is a testament to the skillset of the people who work at Kraya that they are comfortable with Linux. The mindset of Linux is in alignment with the mindset of a developer.

I used to develop in Windows and I often found myself fighting with Windows, whereas with Linux, it just fits. There are several reasons for this. One being that Linux forces you to understand what you (trying to ) do to a bit more depth instead of pretending its magically taken care of.

I am not, for one moment implying that developers who use or develop on the Windows platform is inferior or not as skilled. Simply that my experience was that the Windows platform made it easier to do things badly and more difficult to do things well.

Microsoft has done wonders in bringing technology to the masses and making it more accessible. However, there is still a massive barrier, even for people specifically in the technology sector to appreciate and use technologies which require a bit more experience or knowledge to use appropriately.

There are a couple of really good examples. PostgreSQL is a powerful outstanding database server that can easily compete with Microsoft SQL Server and Oracle. However, very few people know about it and even fewer use it.

MySQL on the other hand is also an open source database server but is much more widely used and accepted.

It surprises me when MySQL is used when PostgreSQL is, from a technical perspective better suited. MySQL is faster than PostgreSQL at the cost of poor transaction managment (at best). For any system where data integrity is even remotely important, PostgreSQL is a better choice. However, since there are better GUI tools for MySQL and since it is easier to get the hang of, it gets chosen.

This give technology and people in that sector a bad name. Every tool or software has its place, and should be used in an environment where its strengths are displayed, not its weaknesses. We have instances where we use multiple database servers within one project. PostgreSQL for all the data integrity sensitive areas and MySQL for the speed sensitive areas. Sometimes you want integrity and speed. In these cases, you have to make a choice based on which is more important or layer the databases to use the strengths of both.

Metaphorically speaking, MySQL is a hammer, and PostgreSQL is a sledgehammer. Would you use a sledgehammer to crack a nut, or a hammer to crack a slab of concrete?

Before someone jumps down my throat, I am not suggesting that PostgreSQL is better than MySQL or vice versa - just that they both have different goals, different strengths and weaknesses. They have spent a lot of effort to converge and strengthen their weaknesses but not matter the amount of convergence, their core goals are still different that they will never truly be able to remove their weaknesses without giving up some of their strengths as well. One tool cannot be both a hammer and a sledgehammer…