Support

We used to support PostgreSQL, but we stopped. We only ever had 3 users for it. Not 3 percent of our clients (which is already unsustainable). 3 clients. In total. The cost for that was astronomically higher than the ~300 Euros we made off those clients, so we axed that support as nonsensical.

According to Joomla's official usage stats from recent sites, PostgreSQL usage is less than 0.8% and this includes all the development sites. The real usage for PostgreSQL is around 0.1%.

Developing and testing for PostgreSQL is much more expensive than doing so on MySQL, especially for Akeeba Backup (PostgreSQL does not have any way to dump the structure of a table, only its contents). We also need to duplicate all of our infrastructure for everything that supports PostgreSQL.

The numbers don't add up. We have to spend a heck of a lot more money to support something used by way too few people. We would never even break even in our investment, let alone make a profit.

To put it into perspective, having a PostgreSQL–specific version of Akeeba Backup and Admin Tools would require us having prices in the range of 20000 to 25000 Euros per year per site to make a realistic return of investment. At the same time, it would make it impossible for us to maintain our free of charge extensions because there's only 24 hours in a day. Both of these are unrealistic. So, no, there's not going to be a PostgreSQL version.

You will quickly find out that most developers did the same math, and for this reason most extensions are written with MySQL only in mind. Trying to run a site on anything-but-MySQL means that you're happy only using the core as people have found out over the last decade that Joomla! added support for non-MySQL databases.

You can do that, but the restoration will be a pain in the rear.

Set the backup type to "Site files only". This will just back up your files.

However, since there is no database backup, there is also no restoration script. No restoration script means that restoring the site requires you to (in this order):

1. Extract the files only backup
2. Restore your database backup
3. Make any necessary changes to your configuration.php, .htaccess, php.ini, and .user.ini files if necessary.

At this point you are basically using Akeeba Backup as a glorified version of zip or tar. I am not sure if there's much utility?

Nope. There is nothing similar.

The reason is simple. PostgreSQL is written with big, cohesive applications in mind. In this case, the structure of the database (a.k.a. "schema") is part of the application itself. You can always go from a blank database to a database populated with the mostly empty, default database tables running a single migration (a process which executes the database code required to create or update the database structure). Therefore, if you only have a copy of the data contained in the tables you can restore the application from them. First you'd run the application migrations against an empty database, then you'd restore the data backup. This is why PostgreSQL only offers data backup, not any way to back up the structure of the tables.

This approach is impractical for Joomla, WordPress, Drupal, and generally everything else which is compiled from a collection of third party software components which each follows its own release plan. You do not have a single, cohesive application. You do not have a single schema. You would have Joomla's schema, Akeeba Backup's schema, HikaShop's schema and so on and so forth. Joomla and WordPress do not even have the concept of migrations.

Well, Joomla kinda-sorta does offer a sort-of database migration by running arbitrary SQL scripts defined in the extension manifest's XML file — different ones for a clean installation and an update. The way this works, the structure of your database tables may differ depending on whether you have been updating from previous versions of an extension, or installed it from scratch. The migrations are NOT idempotent. That is to say, event the largely impractical way of installing Joomla, the EXACT versions of backed up extensions, and THEN restoring the site is not guaranteed to work! We might end up with a different database structure than what we backed up from, causing the database restoration to fail.

This means that we MUST have a way to dump the structure of every database table, as well as any other database artefacts (views, procedures, functions, triggers, relations, counters, indices, …) in an idempotent way. With MySQL half of the idempotency problem is solved thanks to its ability to dump the effective DDL of its current database schema. The other half of the idempotency problem is solved with the code in our restoration script.

With PostgreSQL we have to somehow derive the DDL of the current database schema ourselves, since PostgreSQL itself won't tell us. There is literally no good way to do that. In the past, we had the Reverse Engineering Database Dump Engine which was using the information in the INFORMATION_SCHEMA database (part of the ANSI SQL specification) to derive the DDL. However, that DDL was not fulfilling the idempotency goal. The INFORMATION_SCHEMA does not have all the information we need. The DDL we produced was a usually "good enough" approximation of the database schema, not the exact database schema we were backing up. The restored site usually worked… but extension updates usually didn't, because their update SQL scripts were expecting one kind of database schema and instead found a different one in the database.

Solving that problem is extremely hard. It requires a massive amount of research nobody else has done before. This means pouring hundreds of thousands of Euros into it over several years. I don't have that kind of money and even if I did I would not waste it like that, knowing that the Joomla market for PostgreSQL is infinitesimal at best (it would take millennia to break even). Therefore, that feature was discontinued.

You should understand that nobody will ever do this kind of research because of who the PostgreSQL target audience is: large applications with cohesive, singular, well-defined database schemas. Because of that, PostgreSQL's target audience does not need to have a way to dump the database schema, therefore this feature is not even considered. Joomla on PostgreSQL might be the only use case out there where this feature would make sense, and it's so infinitely small that it can be ignored.

The only way to fix Joomla on PostgreSQL is to remove support for PostgreSQL. The reasons it's still included are not practical, or even based on the reality of usage, they are political. Some people don't want to admit they were wrong in 2011. That's the entire reason PostgreSQL is still present. It would take a massive, backwards incompatible change for Joomla to add proper, idempotent, database migrations for all extensions. Only in this case would backing up a Joomla! site running on PostgreSQL would have a cat's chance in hell of being a valid, usable backup.

You would have to write your own CMS. As long as you go the route of assembling something out of standalone, functional pieces you have the problems I explained.