Forq vs Other Message Queues

Let me start with saying this: if you’ve been using some particular message queue for your projects, and it works well for you, there’s no need to switch to Forq. Stick with what works. I bet your tool is more powerful than Forq will ever be (by its design). Unless you are bored and would like to waste some time on migrating to something new, just for the sake of it.

However, if you are either starting a new project, or looking for a simpler alternative to your current message queue, Forq might be a good fit.

Let me show you a few things that Forq does differently for better or worse.

Self-hosted#

Forq is a self-hosted message queue. You run it on your own server, VPS, or cloud instance. No vendors, no third-party services, and I mean it to stay that way.

This is different from many popular MQs out there:

• AWS SQS: Fully managed service by Amazon. No server management, but vendor lock-in.
• Google Pub/Sub: Similar to SQS, fully managed by Google Cloud.
• Azure Service Bus: Microsoft’s managed message queue service.
• Kafka: While you can self-host it, it’s rarely a good idea due to its complexity and resource requirements. Therefore, many use managed services like Confluent Cloud, AWS MSK or Aiven.
• RabbitMQ: Can be self-hosted, but often used with managed services like CloudAMQP or AWS MQ.

Is this a good thing? It depends.

Good#

• No vendor lock-in. You control your data and infrastructure.
• No surprise costs. You pay for your server, not for message volume or API calls. Works well if you’d rather you service fail under unexpected load than pay a fortune.
• No need to worry about DPA or HIPAA compliance of third-party services if you are dealing with sensitive data.
• Great for self-hosted enthusiasts and privacy advocates.

Bad#

• You are responsible for server maintenance, updates, and backups.
• No surprise costs comes with no auto-scaling. Decide for yourself whether it’s acceptable for your use case.
• Potentially more downtime if you don’t have a robust infrastructure.
• Might be a bottleneck for the very high throughput use cases.

Embedded Database (SQLite)#

Forq uses embedded SQLite as its storage backend. SQLite is a lightweight, file-based database that requires no separate server process.

This means that you don’t need to set up and manage a separate database server. For example, Kafka requires a separate ZooKeeper cluster (seems to be going away), BullMQ has a mandatory Redis dependency, etc.

On the other hand, it brings some limits to the table.

Good#

• Simple setup and deployment. No need to manage a separate database server.
• Minus one point of failure.
• Low resource usage. SQLite is lightweight and efficient, as it uses local IO operations rather than network calls.
• Lower costs. No need to pay for a separate database service, which might be significant if you an indie dev with a very tight budget, and just need a simple message queue.

Bad#

• Embedded DB means that there can be only 1 instance of Forq. No horizontal scaling. Which means that if Forq server is down, your message queue is down, and there is nothing you can do about it.
• SQLite can handle a decent amount of load, but it has its limits. If we are talking tens of thousands of messages per second, even vertical scaling might not be enough. While things like Kafka can (theoretically) scale almost infinitely.

Very Opinionated#

I’ve mentioned this a few times already, but Forq is very opinionated in its design and feature set. On the contrary, many other MQs try to be as flexible and feature-rich as possible to cover the needs of a wide range of use cases.

Therefore, Forq might be either just the perfect fit for your use case, or completely unsuitable.

Side Project rather than Enterprise Solution#

Forq is built single-handedly by me to cover my own needs and the needs of small to medium projects.

Solutions like Kafka or RabbitMQ are built and maintained by large teams of engineers, and have a lot of enterprise features that Forq will never have. They have large communities, and huge plans for the future.

Forq us a different story: I decided to make open-source but contribution-closed. I plan to make it feature-complete soon, and then just maintain it with bug fixes, security patches, and minor improvements. Basically, the idea is to offer a simple, reliable and stable MQ that “just works”.