The Bad Workman Blames His Tools

A tiny handful of you will have read, second-hand, the account of the recent Estonian elections. For the rest of you, here's the facts:

The Estonian government IT vendor, Helmes, had a contract to provide live election data during the recent Estonian parlimentary elections. To do this, they built a brand-new system, which was apparently not tested in advance of the elections. Unsurprisingly, the system failed, and election statistics were delivered hours late.

Why I'm commenting on this is that
Helmes blames PostgreSQL for the election delay. This is the equivalent of a driver blaming his engine manufacturer after getting into a car accident while running a red light. "If only the engine had more pickup!" Helmes laments, "we could have got through that intersection before the other cars started up!"

Assuming that Google Translate is reasonably correct, Helmes has a truly fanciful explanation for the lack of testing:

"The only way to prevent this situation would have been pre-loading the database with the same volume of sample information, which at the height of the election.This is not normal since launching the system may not be a volume of pseudo-data in the database."

In other words, Helmes never tested the system with the database fully populated. A classic beginner's mistake.

PostgreSQL currently powers elections in Argentina, New South Wales Australia, New Zealand, and several Brazillian states. All of these regions (well, maybe not NZ) have significantly larger voting populations than Estonia, and nobody in those places has reported election-hampering performance problems. Heck, I know of election systems powered by SQLite, and those work fine as well,
because they were designed correctly.

Closer to Helmes, Estonian VOIP vendor Skype manages more than 6% of the long distance calls in the world using PostgreSQL. That's around a billion transactions a day. Worldwide, PostgreSQL powers many systems which process the equivalent of several Estonian elections ... every hour, day in and day out.

My advice to the Estonian government is: fire Helmes. You don't need a company which fails to deliver and then blames their tools for doing so.

If any of my readers are Estonian, please translate this blog post and share it with the people of Estonia.

(Also, I can hear the MySQL folks laughing at us now. Now we know what it's like to be blamed for failures to use our database correctly.)

For the rest of you, here's the facts:
[...] which was apparently not tested in advance of the elections. [...]
In other words, Helmes never tested the system with the database fully populated.

What is this conclusion based on? The contractor has claimed that the system was tested.

I guess this conclusion is based on this quote from the article:

""The only way to prevent this situation would have been pre-loading the database with the same volume of sample information, which at the height of the election.This is not normal since launching the system may not be a volume of pseudo-data in the database.""

That basically says they tested the system with much smaller amount of data than actually collected during elections. Something like ""let's do the whole testing using 10 rows in each table"" or something like that (so that you don't have the proper indexes). "