Not planned Will xenforo be ported to postgres?
- Thread starter jtorral
- Start date
Mendalla
Well-known member
For sure. Supporting two platforms would be a ton of work for both them and third parties. And switching completely would wreak havoc on the self-hosted community, since many of us on shared hosting only have MySQL/MariaDB as an option.
digitalpoint
Well-known member
Postgres isn’t bad, but there are storage engines in MySQL that make Postgres look like an Excel spreadsheet. I use ndbcluster storage engine exclusively these days and allows all sorts of interesting things… fault tolerance without slaves (every node is fully write capable), ability to take down nodes or servers with zero downtime for users, backups without any locks, 10M SQL writes per second (while also doing 50M SQL reads). The bottleneck becomes your network connection and how many SQL queries you can push down your network connection (I run server interconnects with 54Gbit Infiniband just for that).
My point is that MySQL already has support for something that is next-level over MyISAM/InnoDB or Postgres.
It was originally designed for call logging in phone companies where a single second of downtime was not an option (even for planned upgrades).
www.mysql.com
My point is that MySQL already has support for something that is next-level over MyISAM/InnoDB or Postgres.
It was originally designed for call logging in phone companies where a single second of downtime was not an option (even for planned upgrades).
MySQL :: MySQL Cluster CGE
jtorral
Member
Appreciate your opinion on the MySql / Postgres. Both databases have pros and cons. But that's about it. I have been supporting Postgres since 7.x version and have consulted and implemented solutions in Postgres for fortune 100 companies that I cannot disclose due to NDA's. But lets say these companies are in the Billions as far as revenue goes. In fact, we just finished migrating an Oracle based solution to Postgres with an annual savings of 7 million in licensing fees. Insane. Lets not forget who owns MySQL 
Having said that, fault tolerance without slaves has been there for many years mainly with Aurora. Hot backups have never been an issue for Postgres and can be performed regularly. And lets not forget the MySql was not even acid compliant until innodb became the preferred storage engine. Parallel query processing as far as I can recall was not even possible until mysql 8. As far as reads and writes, postgres can achieve insane throughput using citus. Postgres can achieve full upgrades with zero downtime as well. RDS even offers their DMS which can get close to this. Dare I say declarative partitioning and sub partitions with parallel querying and partition exclusion? that's been around for a while as well. There are 10,000 ways to skin a cat
Lets not forget Discourse They run on a Postgres backend. So who knows. Maybe one day XF will be available in postgres as well.
Regardless of database wars I am in the middle of porting my gallery and classifieds app which runs on a postgres backend to integrate with Xenforo which runs on Mysql. Glad to say i have both database engines talking to each other using Postgres FDW's with minimal effort.
Having said that, fault tolerance without slaves has been there for many years mainly with Aurora. Hot backups have never been an issue for Postgres and can be performed regularly. And lets not forget the MySql was not even acid compliant until innodb became the preferred storage engine. Parallel query processing as far as I can recall was not even possible until mysql 8. As far as reads and writes, postgres can achieve insane throughput using citus. Postgres can achieve full upgrades with zero downtime as well. RDS even offers their DMS which can get close to this. Dare I say declarative partitioning and sub partitions with parallel querying and partition exclusion? that's been around for a while as well. There are 10,000 ways to skin a cat Lets not forget Discourse
They run on a Postgres backend. So who knows. Maybe one day XF will be available in postgres as well.Regardless of database wars
I am in the middle of porting my gallery and classifieds app which runs on a postgres backend to integrate with Xenforo which runs on Mysql. Glad to say i have both database engines talking to each other using Postgres FDW's with minimal effort.
Max Taxable
Well-known member
Curious.
digitalpoint
Well-known member
XenForo uses abstracted database adapter, so if someone wanted to make a Postgres adapter, it would be relatively easy and then then you just set in your config file which database adapter to use. So the framework is already there for someone who wanted to use Postgres. Would probably be about 15 minutes of work and would maintain across upgrades without any issues.
I presume they mean Oracle but mysql is free and open source so
Max Taxable
Well-known member
That's why I'm curiousI presume they mean Oracle but mysql is free and open source so
digitalpoint
Well-known member
So I was went to get the path for the MySQL adapter XenForo uses and I noticed there already is a Postgres adapter (not a third-party vendor that has some random thing in there, it's from XenForo).
Looks like there are a few minor things that can't be duplicated in Postgres, but it looks like the fundamentals are already there.
Looks to me like someone could add this to their config.php and (maybe) it would already work?
It would probably make sense to build on that adapter to work around some of the things since there are some places where lastInsertId() is needed/used, so just throwing an exception wouldn't really work.
XF\Db\PostgreSql\Adapter.phpLooks like there are a few minor things that can't be duplicated in Postgres, but it looks like the fundamentals are already there.
PHP:
public function lastInsertId()
{
// note: no (viable) equivalent in PostgreSQL
throw new Exception('It is not possible to retrieve the PostgreSQL last insert ID at this time.');
}Looks to me like someone could add this to their config.php and (maybe) it would already work?
PHP:
$config['db']['adapterClass'] = 'XF\Db\PostgreSql\Adapter';It would probably make sense to build on that adapter to work around some of the things since there are some places where lastInsertId() is needed/used, so just throwing an exception wouldn't really work.
Max Taxable
Well-known member
And the problem is?
Mendalla
Well-known member
It was. And if you want MySQL without Oracle, Maria is probably the way to go (my site runs on Maria since that's what my shared hosting uses). It has corporate sponsors but so does PostgreSQL. In fact, MS and some others sponsor both. It's just that both have enough of them that no one can dominate vs. Oracle being in control of MySQL.
Huh. So you could also try to adapt it to SQL Server or something like that? Not that you'd want to. SQL Server is more than a tad bloated, being MS and all. But in a corporate environment where you had it licensed and running for other purposes...perhaps.
nocte
Well-known member
jtorral
Member
Well, there is no problem ( yet ) while you can still get non enterprise edition. And, MySQL has improved under Oracle. So that is all good. But there are still licensing concerns that may pop their ugly head sooner or later. Generally speaking, unless you work for oracle, It is considered an evil entity Please take that as a jest. But yes, when a company offers training material on how to license their product, you need to be suspicious.
Please take that as a jest. But yes, when a company offers training material on how to license their product, you need to be suspicious.
Mendalla
Well-known member
Given a choice between MS and Oracle, I'll take MS but that's a case of the better the devil you know (over twenty-five years as an MS admin on two jobs)...Well, there is no problem ( yet ) while you can still get non enterprise edition. And, MySQL has improved under Oracle. So that is all good. But there are still licensing concerns that may pop their ugly head sooner or later. Generally speaking, unless you work for oracle, It is considered an evil entity
digitalpoint
Well-known member
Yep, but it doesn’t have a call to get the id from the last insert. It’s close, but not quite the same. There are also times where you need to get the last ID decoupled from the SQL query that caused the insert. It's nothing that can't be worker around though. Basically if someone wants to use Postgres, the only changes they would need to make is within the Postgres database adapter (or make one of their own). The database adapter system is abstracted out so all queries pass through the database adapter class you specify.
Someone would simply need figure out how to replicate anything that's MySQL-specific. For example instead of
Either way, XenForo's database adapter is abstracted out already... and that's 99% of the work right there. It's a relatively simple coding exercise to finish the Postgres adapter that XenForo already did 95% of. The coding time to do it is less than the time people have spent writing posts in this thread.
Someone could make a Microsoft Access 95 database adapter if they really wanted (would probably need to do some silliness with ODBC drivers to get that to work with PHP, but it could be done).
Either way, Mysqli is simply the adapter that XenForo defaults to. But can use any one that you have/build and apply it with a single config.php line that tells XenForo which adapter to use.
Someone would simply need figure out how to replicate anything that's MySQL-specific. For example instead of
SELECT LAST_INSERT_ID(), could do some trickery with SELECT CURRVAL pg_get_serial_sequence(blah, blah).Either way, XenForo's database adapter is abstracted out already... and that's 99% of the work right there. It's a relatively simple coding exercise to finish the Postgres adapter that XenForo already did 95% of. The coding time to do it is less than the time people have spent writing posts in this thread.
Someone could make a Microsoft Access 95 database adapter if they really wanted (would probably need to do some silliness with ODBC drivers to get that to work with PHP, but it could be done).
Either way, Mysqli is simply the adapter that XenForo defaults to. But can use any one that you have/build and apply it with a single config.php line that tells XenForo which adapter to use.
The Postgres adapter was made for the Discourse importer. There's likely to be a fair number of queries in the core which are specific to MySQL, so fully swapping out the database engine would require more significant changes than just switching the adapter. There are no plans to support alternative database engines at this time.
Similar threads
- Question
