"Database queue" working with postgresql for the 2.0 beta?

esbeeb

I'm using postgresql (stock deb packages in Debian 13). I can find no straightforward attestation to this working with Flarum (nor find a clear setup procedure).

My intent is for email notifications to get sent via database queue.

KBExit

esbeeb You can use the Redis extension as an alternative and I highly recommend this over Database Queue as it can be scaled more efficiently and it operates instantly vs. waiting every minute for a process.

Edit, it appears to me that Database Queue is database agnostic. Should work with Postgres, but don't quote me 100% on it as I don't use that database personally.

Edit #2: I don't think Dev is the correct tag for this either.

esbeeb

I'm not really a fan of Redis, and would prefer to use postgresql if possible (fewer "moving parts" to the system).

BTW: No mention of postgresql in the following places:

This gives me a feeling that postgresql is sort of a "second-class citizen" in the Flarum world. I would hope that setup of this database queue was a streamlined part of a normal flarum install (and becomes prominently mentioned in the installation docs, as a final step)

esbeeb

KBExit Edit #2: I don't think Dev is the correct tag for this either.

KBExit Maybe this is merely a documentation issue?

KBExit

esbeeb Postgres is not "part of the normal flarum install."
Normal Flarum is: MySQL / MariaDB.
Postgres and SQLite are options brought in for Flarum 2.0 and I believe are still 'experimental' right now as it is not widely adopted by the masses.
And configuring Redis is not adding too many moving parts into your system. Implementing it will help your website tremendously in the user experience and how your site operates.

I can go on and on with how Redis is a lot better, but you probably won't care for it.

KBExit

esbeeb no, you placed this post in "Dev" when it really should be in "Support."

esbeeb

I do appreciate your replies. I'd be curious to see how well a postgresql database queue can scale for user load - can it gracefully handle a couple hundred casual users on hardware like a Raspberry Pi 5 (8 or 16GB of RAM)? Then it would be good enough, without taking it to the next level - Redis.

esbeeb

KBExit still 'experimental'

thus my cautious attitude. We'd all hope that the backend (postgresql) works just the same... but this remains to be seen.

KBExit

esbeeb it depends. RAM is important, but how much CPU are you operating off of? Is your database in the same pool as your website?
Database Queue can handle decently sized communities, but you'll find it very limiting compared to Redis. I still recommend Redis over Database Queue as it's an extremely optimized and small footprint that can scale. Valkey is great and it's what I use with all of my customers.
Database Queue is only appealing to community admins for it's easy setup. It's not ideal for "couple hundred casual users."

KBExit

esbeeb I believe Flarum's approach is to be database agnostic moving forward to support many database frameworks, but the issue with this is not on Flarum, but on the database developers themselves. Take a look at the breaking changes between MySQL and MariaDB with Ghost CMS for one example. They strictly require MySQL now from the result of it.

To be best cautious, I would say the best approach is to stick with MySQL. As it is universally adopted.
But you're on the 2.0 Beta and using Postgres. I think your cautious window is thrown on at inception lol.

GreXXL

esbeeb what exactly is not working? If you run the scheduler (which you can run via a cronjob) then the queue should work out of the box. Maybe you can describe the problem you see in more detail.

KBExit

GreXXL I think they want to know if it would work regardless of Database Structure. I told them I believe it is Database Agnostic so it should work.

GreXXL

KBExit yes that's right. It should work just fine with Postgres but yes it's newly introduced with Flarum 2 so there could be issues in core as well as in extensions coming our way specific to Postgres.

KBExit

@esbeeb I do want to stress that you seem to be putting "Hundreds of Casual Users" on a small Raspberry Pi using Flarum 2.0 on Postgres.
I don't think that entire configuration is SAFE for production, rather local test / development instead.
You have every right to configure your setup as you wish and how you want to run it, but I don't think this is a safe reliable approach.

esbeeb

KBExit Is your database in the same pool as your website?

Yes same pool. Note: I could split the database off to a second raspberry pi 5 if necessary (with GbE between the two) if really needed, but would prefer not to.

KBExit Valkey is great and it's what I use with all of my customers.

I would sooner use Valkey than Redis, just saying.

KBExit

esbeeb Valkey is just an open source fork of Redis lol.

esbeeb raspberry pi 5

I would recommend a proper VPS. But that's just me.

esbeeb

KBExit just an open source fork

There's always some grey area when measuring risk, when weighing the smallish differences between Redis <-> Valkey, MySQL <-> MariaDB, or MariaDB <-> Postgresql.

esbeeb

esbeeb https://flarum.org/extension/flarum-com/database-queue

No mention of systemd timers, the newer and preferred alternative to cron in Debian 13. cron is basically deprecated in Debian 13. There's a way to sort of allow backwards-compatibility for cron jobs from a systemd timer, but I sort of don't trust it (has bitten me before).

GreXXL Maybe you can describe the problem you see in more detail.

No mention of systemd timers (and a setup procedure involving them) is my issue.

KBExit

esbeeb I understand, the technology is still "Redis." Valkey is an opensource fork of it. By mentioned "Redis" I am suggesting the technology, not the specific stack. The extension is called: FoF/Redis and it is compatible with Valkey, to clarify.