EMQX Reviews

I use EMQX for MQTT pub/sub use cases with devices connected through IoT. When communicating between different devices, EMQX provides the connection between them and delivers real-time updates.

Devices are deployed with MQTT TCP connections. Device credentials are created inside EMQX for each particular device, and those devices have those credentials with a specific client ID to communicate through the web app. The web app listens to a particular set topic which that particular device generates. That particular device sends data to that particular topic, and the application listens to that topic. In that case, they communicate with each other. When the application needs to provide some commands to the device, those commands are sent through command topics, and the devices listen to those. These communications happen in near real-time.

Webhooks provided by EMQX are also leveraged to fetch real-time connection details for the particular devices that are connected. EMQX provides functions to make real-time changes based on the events received from that webhook. The built-in monitoring from EMQX is also used for managing clients inside the EMQX dashboard.

EMQX is a solid open-source project for making IoT devices connect anywhere in the world. The main use case that stands out is the TCP connection, which plays a vital role inside the IoT device ecosystem. The pub/sub functionality and how publishers and subscribers interact with each other without disrupting the connection between devices and applications is outstanding. The best part of EMQX is that it provides unlimited authentications and authorizations. Different providers can be integrated between those authentications and authorizations. Authentication can be provided with the built-in database within an application. Authorization can be provided based on specific users who can perform specific actions on those devices, and those actions can be controlled inside the EMQX instance. EMQX is very versatile in those terms, and people can leverage those features mostly from the EMQX platform.

When going with the open-source EMQX version, there are limitations provided. For example, the webhooks use case cannot be scaled to as large a scale compared to the enterprise edition of EMQX. The open-source version helps a great deal with work in the company. The way this resource helps nurture the IoT device paradigm is greatly helpful for developers working newly on this system because the onboarding part of EMQX is very easy and developer-friendly. Someone who wants to dive into it can easily implement and make the system robust based on the technologies it provides.

EMQX provides API connections for applications. HTTP calls can be made to EMQX to get updates from the client. Those connections should be made asynchronously. The webhook part handles this well, but when it comes to the API part, when the load and payload of the MQTT topics and messages are very heavy, sometimes unknown errors occur, and logs and errors must be found. When a specific log session is created for that client, the readability of those logs is not good. The platform itself does not need improvement, but when it comes to developer-friendly implementations of EMQX, there are some pain points that need attention. The visibility of logs, error logs, and information logs inside the built-in monitoring needs work because developers, when they implement code or any kind of specific tools, need proper control over the system. Without that control, there is no point in implementing anything at all.

The monitoring part needs work. When it comes to the flow chart of how different clients are connected with different devices, there is a feature inside EMQX called Flow. When that Flow is in place, clients (devices) should be controllable from that Flow itself. These are the most important improvements that need to be addressed.

I have been using EMQX for more than three years.

If the machine and the environment in which it is deployed are stable, there should be no downtimes. When EMQX was deployed on production, it did not cause any problems. It is a production-grade tool that has been tested and is used in production by many organizations.

Scalability has not been an issue thus far. EMQX has handled growth from thousands of devices to millions of devices. There are no scalability caps being hit, and it continues to support growing needs.

The open-source version of EMQX is used, so there is no customer support to speak of. The documentation is exceptional and so developer-friendly that customer support is not needed. The documentation has been maintained very much with developers in mind.

The organization previously used other options such as VerneMQ or HiveMQ. When the switch to EMQX was made because it was so developer-friendly, there was no need to go back and re-implement VerneMQ. The organization moved on to EMQX and stayed there because it provides so much value to the product. There was no reason to look back, and that represents the return on investment. As a developer, if time is invested and a POC stays for the longer run, that is what return on investment means.

The previous solution was VerneMQ, and the switch was made because the implementation of authentication and authorization was not developer-friendly, and there was not much control over the schemas from a developer perspective. With EMQX, a schema is defined and everything is controlled by the organization's own IP. Whatever the use case is, it can be played around with, and security gateways can be implemented easily. With VerneMQ in place, that was not nearly as easy.

The relevant metric is the ability to grow from tens of thousands to millions of devices.

The open-source version of EMQX does not have a specific cost. When it comes to the deployment of the whole application as a whole, there is no specific number because AWS costing for the product that is maintained is quite high.

When switching from VerneMQ, EMQX was the first solution looked into while conducting the POC. When it satisfied all use cases easily, there was no reason to look back, and it was implemented right away because there was no desire to waste time. EMQX provided value right away. No other solutions were used or considered.

For a backend written in MySQL or MongoDB, specific users and ACLs inside MongoDB or SQL can be leveraged to integrate with authentication and authorization without relying on any outer-world providers. The company's domain will control the authentication and authorization for these devices. Overall, the devices are maintained inside the system, not anywhere else. This provides leverage between different authentication and authorization providers.

The organization was able to manage 1,000 plus devices and 65 million concurrent device connections with EMQX. Different clients use these EMQX pub/sub relationships, and it helps greatly, providing the versatility and extensibility of this particular platform.

For those wanting to implement a workflow where devices are present or real-time actions are needed from some client residing on the other side of the network, it is important to first know the use case. When the use case is finalized, a POC on EMQX can be conducted, which is easy to do because the documentation provides great support. For developers implementing it, the authentication and authorization part should be prioritized because that is the most important part for making clients secure. If security is compromised there, then the whole point of making connections secure is lost. Keep a close lookout for the authentication and authorization part so that wherever clients or devices are placed, they are secure and securely managing their communication between networks.

Anyone wanting to implement EMQX in their workflow can rely on the tool because it provides features that every organization has, and the use cases it solves are immensely valuable. Going ahead and implementing these tools puts an organization ahead of the game from other players. This review rates EMQX an overall score of 8 out of 10.

My main use case for EMQX is transporting messages via WebSocket and TCP for streaming data, specifically streaming prices on the trading board of VNDIRECT.

For chatbox messaging or data streaming, I use EMQX as a message broker. When a user sends a message, I use EMQX to send that message to people in my room. With the trading bot, I use EMQX for streaming messages. When I receive a message from Hanoi X and HoSE, I convert the message and send it to the customer who is using a trading bot to monitor price changes.

I use EMQX for my chat platform and message streaming for a trading bot.

The best features EMQX offers in my experience are that it can send messages for a large number of customers with a very high message-per-second rate while consuming low resources. When I use an EMQX cluster with three node cores with four CPUs and eight gigabytes of RAM, and three node replicas with eight CPUs and 16 gigabytes of RAM, I can send outgoing messages up to two million messages per second for all my customers who are online at that time.

EMQX has good performance and sends messages with low latency. When I send a message, the latency is less than 100 milliseconds, which is very improved message latency.

When I changed from a trading bot using WebSocket to EMQX, I was able to cut down costs by half of the resources from before. My service has durability and scalability that is very easy to achieve.

To improve EMQX, I think it should reduce costs, save time when sending messages, and improve reliability.

Regarding needed improvements, I think EMQX should improve setup time. EMQX cluster setup is not easy. Additionally, I think EMQX needs to improve its logs. When I encounter a problem with EMQX error messages, it is very difficult to trace the logs and find the real reason for the error to fix it.

I have been using EMQX for three years.

EMQX is very stable since I have been using it for three years.

EMQX's scalability is very easy to manage.

When performance is high, we only need to add a node replica.

I previously used a different solution before EMQX.

Before EMQX, I used WebSocket. When I changed to EMQX, I found that EMQX is very good for my needs.

I do not purchase EMQX through any cloud marketplace; I download EMQX and set up the free version.

I have seen a return on investment by lowering the resource cost by half.

With my experience of pricing, setup cost, and licensing, I am not buying a license because I am using the free version of EMQX.

Before choosing EMQX, I evaluated other options such as Mosquitto and other MQTT protocol solutions, but I do not remember all the tech stacks I researched, as it was a long time ago.

My advice to others looking into using EMQX is that if anyone wants to use it for their microservices, they can try it. EMQX is very good for new developers who want to use it.

EMQX is a very good solution for a system with high performance and large throughput messaging for clients using mobile or web applications. You can use the WebSocket feature of EMQX with SSL on port 8084. You can also use other features of EMQX such as webhooks. When I used authorization of EMQX, I faced issues regarding high load performance in my service backend. Therefore, anyone wanting to use authorization of EMQX should use Redis Auth. We changed from webhooks to using Redis Auth, and we achieved better performance. EMQX is a good solution if one is using authorization. I give this review a rating of eight out of ten.

We considered EMQX because we initially used the MQTT broker Mosquitto, which does not support the higher sampling rates that our product requires. Our product needs to transmit nearly 16 KB of data per second, which is substantial, but Mosquitto broker cannot support that capacity. We switched to EMQX so that it can open multiple channels to send the data simultaneously to achieve the sampling rate as effectively as possible.

For example, I have an ADC connected to a microcontroller with eight sensors. The ADC takes raw data without any overhead of internet connectivity or HTTP calls, and the raw sampling rate of the ADC is nearly 128 samples per second. When transmitting the data, it suddenly drops to nearly ten samples per second, which represents huge data loss when considering medical, transportation, or any devices used by humans. We signed up for EMQX, and EMQX created simultaneous eight channels, increasing the rate from ten samples per second to nearly 80 samples per second. We initially used the free EMQX offering, which supported nearly 250 users, and then we moved to serverless, which is what we are currently using. Serverless supports nearly 16 channels, so 16 multiplied by 10 means we can achieve nearly 160 samples per second. That is the real-time scenario for which we have used EMQX.

You can use EMQX when you want to get a major amount of data to the internet. When transmitting data via HTTP, there is a minimum delay of 200 milliseconds, which is significant for IoT products. For that reason, we are transitioning to MQTT, which stands for Message Queuing Telemetry Transport. When moving to MQTT, there are many constraints that we faced in free MQTT options such as Mosquitto broker. EMQX will boost your product sampling rate and transmission so that you can achieve a large amount of data without any loss while transmitting through the internet. If you are planning to build an AI product using an IoT device, each data point will count. With EMQX, you will get many data points per second and over time spans to boost your AI, and the AI will be trained faster compared to other brokers.

The best feature for EMQX is that it supports many additional features. For example, if you do not want to own a server, you can directly purchase serverless. If you are using another broker and have deployed that broker onto a server, when the user count of your product increases, you would need to own another server, which will cost more. However, with EMQX, you can boost your subscriber count in the EMQX portal to fit more users into your product. That is nearly scalability in AWS in cloud terms, which I appreciate in EMQX.

When I started using the free feature, it supported 250 clients, but they have since reduced it to a significant degree. I do not know the exact number because I have moved to serverless. The free feature is beneficial to startups, so if you are doing a college project or a prototype, the free EMQX is very effective. You can use any server, whether it is Windows, Linux, or anything else, and it will be supported. That is a positive aspect, and it is supported in the free feature as well.

EMQX has improved significantly, and it is one of the greatest solutions. If you want to improve further, the SSL certificate and TLS certificate have overhead in serverless EMQX. If there were an option to utilize serverless without that TLS and SSL overhead, the embedded system would not experience the overhead burden. The embedded system would not need to perform a handshake each time it wants to transmit. That is one area that should be implemented in EMQX serverless.

3.5 years

EMQX is a unified architecture and unified namespace based on MQTT broker, primarily using EMQX or HiveMQ. We use EMQX for the communication of factory data, sensors, and PLCs.

We track data on sensors and MQTT data by collecting MQTT data for sensors and publishing it to the MQTT broker. We then fetch MQTT data again, calculate some KPIs, and publish these KPIs back to the MQTT broker.

We primarily use energy data for reducing energy costs and calculate the machine state of machines. We use EMQX and MQTT mostly for the machine state of machines. We collect machine data, such as temperature or pressure and sensor values in machines, and then calculate the machine state of the machines or lines. We collect energy data of these machines in energy analyzers and calculate the total energy of the products.

The best features EMQX offers include fast communication; MQTT is the fastest protocol that I have observed.

MQTT scalability is excellent, and I am using the REST protocol. The REST protocol is not scalable as it is an old protocol, but MQTT runs a pub-sub mechanism and it is very fast and very scalable. This is excellent.

MQTT enables us to use unified namespace architecture. I collect data and publish data to MQTT and use this factory data on the MQTT broker. This enables us to have very fast integrations and data integrations, and I see data when I need it very quickly. When I use the MQTT broker, I do not need a database. EMQX broker is unified.

For example, MQTT 5.0 is a new version that is very fast.

EMQX is a good MQTT broker but the historian is simple. The historian side of EMQX and MQTT is simple and could be better.

It could be more reliable in new versions.

I have been working in my current field for three years.

EMQX is very stable in my experience.

EMQX's scalability is excellent and I have used EMQX for very big data and it is a very scalable solution.

When I need any support, I read forums and there are many articles in forums.

We were using a database, for example, MSSQL or PostgreSQL. In my old experience before MQTT, MQTT is faster than database solutions and more lightweight solutions.

I have seen a return on investment with money saved and time saved because the protocol is MQTT.

EMQX is an open-source protocol. The cost is mostly the cloud provider cost. EMQX is open-source and MQTT is also an open-source protocol, so the cost is less.

I evaluated other options before choosing EMQX.

EMQX is a unified namespace architecture and is a lightweight solution compared to old database solutions such as MSSQL or PostgreSQL. EMQX is also a very fast communication protocol. MQTT is a very fast communication protocol.

I appreciate EMQX as it is a very lightweight solution. This review has an overall rating of 8.

My main use case for EMQX is for the streaming part, as we are a fintech-based startup using EMQX to get stock price details from DriveWealth. We have an MQTT module where we use EMQX as a streaming module to stream the data.

EMQX fits into my workflow as we designed an MQTT module where it helps us to fetch the data from DriveWealth, which is a US-based entity, by using the endpoint where we can get the stream data, thus allowing multiple users to access the stock information.

In terms of my main use case with EMQX, we were using a Docker pulled image of EMQX for the admin panel to see how many clients are connected, how long they are connected, and we have an auth plugin, so all streamed data was able to be fetched with the dashboard.

The best features EMQX offers in my experience include the EMQX configuration file, auth file, and HTTP file, which help us to get the relevant data, and EMQX is fantastic for dashboard creation, allowing us to fetch data for our mobile or web-based applications using multiple sources.

The dashboard specifically helped my team to understand how many clients got connected via our EMQX module connection, allowing us to track the health of the EMQX container, such as CPU usage and real-time connections, all tracked via the dashboard alongside multiple config files managing WSS connections.

EMQX has positively impacted my organization in many ways, particularly by making our main agenda of getting stock details and connecting users to our real-time protocol much easier.

As for improvements, I do not feel any bug or improvement is needed currently; the features are already sufficient for our efficient use, but if AI enhancements or messaging options could be added, that would help us a lot.

I believe that all suggested improvements are already well-built, and if any AI parts are integrated, it would greatly benefit new users. Overall, I am a happy customer of EMQX.

I have been using EMQX for about four years.

I have noticed measurable outcomes with EMQX, as we are mostly happy about the practicability and features offered, which contribute significantly to scalability and helped our product design in a better way.

EMQX is a pretty good product, and I am satisfied with it.

My advice for others looking into using EMQX is that it provides a better and more efficient way of getting data streams and better visualization for your product, along with easy integration and go-to-market solutions. I would rate this product nine out of ten.

EMQX remains live and matured, allowing us to scale it, and we continue using EMQX without requiring to switch to any other offerings as it still works best and is resilient.

EMQX was a completely new feature and the maintenance effort was not there previously, but we did not require any maintenance as far as I recall in the past three to four years, as we did not need anything to restart or connect or reconnect the cluster; it was working smoothly for months and even years. Regarding improvement in latency, latency was just some milliseconds for every message delivery, ensuring all messages were reliably delivered. User engagement was a great experience where users did not face any issues while interacting via EMQX, whether it involved comments, emojis, or anything else. We even built an admin panel for comment moderation, where we saw EMQX messages flowing to the system, meaning the dashboard was very smooth.

EMQX UI is very best, allowing users to easily get used to it without digging through documentation. EMQX also scales well with easy configuration, enabling users to get their cluster created and get started quickly. The consumption from EMQX is very convenient, such as connecting your application to EMQX servers and all nodes, so that was also easy. Performance-wise it was very great; it also offers ACL, options such as message size limitation, blacklisting certain client IDs, and supports MQTT new protocol such as MQTT 2, which is also a good thing.

EMQX allowed us to scale our product very easily, enabling us to add multiple nodes as needed and perform regional deployments such as a standby EMQX cluster. Management was easy as we did not need 24/7 maintenance or support for that since everything was well documented on the EMQX website and the community support was great.

On EMQX improvement side, I saw certain frameworks such as NanoMQTT and others claiming to be much more performant than EMQX, so maybe the newer version of EMQX can look into those aspects for potential improvements, but I do not have insight on the latest version of EMQX to know whether it has already addressed this or not.

I have rated it an eight because I believe there is always scope for improvement, especially concerning more complex use cases and features that EMQX may need to address, particularly due to frameworks such as NanoMQTT and others having much more capability than EMQX, so it would be beneficial for EMQX to look into those aspects and improve further to take it to the next level.

I started using EMQX from my previous organization at Flipkart, where we were building a live stream kind of feature, similar to Instagram Live or a YouTube Premier, wherein a user can come and do comments and exchange emojis. I think it has been around four to five years that we have been using EMQX.

EMQX is much stable in my experience.

EMQX's scalability is great and I think it works phenomenally.

We do not really require to reach out to customer support during our tenure as it was very smooth, but I have never tried it.

It was a brand new use case and we did not have anything in place previously, making this a brand new use case.

The entire cluster we managed required only a team of two members, one being junior and the other senior, such as SDE 1 and SDE 3, so we did not require a large team to maintain our cluster, and we saved a lot of time on setting things up as it was very smooth.

We evaluated RabbitMQ, Kafka, and a couple of others, but I do not recall it exactly since it was four to five years back.

I think others looking into using EMQX can do a small POC to see from all aspects whether EMQX fits their requirements, not just the current one but future expansion as well, before deciding which one is better, as there might be other alternatives to evaluate as well. I have given this product a rating of eight.

My main use case for EMQX is using it as a broker for MQTT. In our projects, we use EMQX as an MQTT broker because we are an IoT-based company where devices are provisioned or connected to our cloud through MQTT, allowing devices to send data to our services, back-end service, or cloud using an MQTT connection through EMQX.

The best features EMQX offers are that it is highly scalable and cheaper than other brokers, plus we can use our own back-end services integrated to it for authentication and authorization.

I find the integration process with our back-end services for authentication and authorization to be smooth.

EMQX has positively impacted our organization because, as I have already mentioned, it is quite cheaper compared to other enterprise-level brokers we were using, and we find it very easy to maintain and manage, making it quite impactful in our company.

I think EMQX can be improved by providing a uniform UI and login feature that we can use in the dashboard.

Additionally, it seems to be a single tenant setup. If we are using a multi-tenant structure, we cannot use it without deploying EMQX dashboard for each instance, which is hard to track. A centralized dashboard where we can add multiple clusters in a single place would be easier to monitor. We also do not find any OAuth integration such as Google login, which would be quite helpful.

I have been using EMQX for about two to three years.

In my experience, EMQX is pretty stable.

Regarding EMQX's scalability, we have never tested it much, but so far it feels okay from our perspective.

The customer support for EMQX is pretty good and helpful, as we get prompt responses from them.

We previously used AWS IoT and switched because it was quite expensive for us.

My experience with pricing, setup cost, and licensing is that it is pretty convenient, though I do not handle the licensing or pricing communication, but I think it is pretty convenient.

Our cloud provider is Google Cloud Platform.

Regarding return on investment, I am not sure about the money perspective, but I heard from my manager that we need one extra engineer to set up things.

We have seen specific outcomes such as cost savings since switching to EMQX, as we are using it for trial purposes and have some licenses based on our usage, meaning we do not need to pay for what we are not using.

Before choosing EMQX, we evaluated other options from AWS IoT to EMQX.

I would rate the customer support ten out of ten.

My advice for others looking into using EMQX is that if you want to achieve cost savings and you want to deploy on your private infrastructure or in your cloud or cluster, you can do so.

I think EMQX is a great product. I have given this review an overall rating of eight out of ten.

My main use case for EMQX is for communicating with ESP32 devices and sharing messages from one device to another device at the central level.

Our company is a fuel automation company, and we will have dispenser units where we connect one ESP32 for each dispenser unit. We get all the data from the dispenser unit and share it to the server via EMQX.

One of the best features EMQX offers is the ability to share data via topic-wise distribution.

Topic-wise data sharing helps my team and our workflow because each ESP32 has a different MAC ID, and using the MAC ID, we filter the data in the server, determining which ESP32 sends which message for a particular dispenser unit.

I would like to add that we are using TLS security for EMQX, and we have created one server where we can use a certificate for security purposes. The speed is really high, and even if there is a large number of incoming data, EMQX handles it very smoothly and quickly.

EMQX has positively impacted our organization by significantly increasing speed compared to other technologies we used before. After using EMQX, we can now handle a large amount of data within a fraction of seconds, which makes it very easy for us to pass the data and store it in our database, and we can easily visualize it in our UI.

The outcomes from using EMQX are very cost-saving for us because we previously used the MQTT Mosquitto broker, and when I compare Mosquitto with EMQX, EMQX is far better than Mosquitto and other protocols.

I do not have any suggestions for improvement in EMQX.

As I have worked with EMQX, I do not feel much improvement is needed. Whatever is available till now is working great and is very efficient for us. Perhaps I need to explore more to add new features or other functionalities, but as of now, it is great for us.

I have been using EMQX for 14 months.

EMQX is much more stable.

EMQX's scalability is really great.

We have not faced any need for customer support from EMQX since we can handle everything on our end.

We previously used the Mosquitto broker, which had latency issues and could not handle a large amount of data, and it was very slow. That is why we searched for an alternative option and found that EMQX is better.

We have not deployed EMQX to a large extent yet, so I cannot provide specific metrics, but we are optimistic about the return on investment.

My experience with pricing, setup cost, and licensing for EMQX is good.

Before choosing EMQX, we evaluated other options, including HiveMQ.

My advice for others looking into using EMQX is that if they want to manage a large amount of data with more speed, reliability, and security, they can easily switch to EMQX compared to other brokers. I give EMQX a rating of 10.

My main use case for EMQX is a stable and scalable IoT message queue.

I use EMQX in one of my projects specifically with ESP32 and Argon and Boron embedded chips, and I program them to send and receive messages via EMQX with MQTT channel.

Regarding my main use case, I'd like to add that EMQX has a good interface and control center, and it's better than standalone MQTT.

The best features EMQX offers include a message queue management system, a dashboard, a control center, and some really useful debugging tools.

Out of those features, I find myself using MQTT streams the most or find them the most valuable in my workflow.

EMQX has positively impacted my organization because we didn't get any issues about MQTT; it just works.

This reliability has saved my team time and resources, as we don't spend time on debugging MQTT or the MQTT server; it just works and saves time.

I think EMQX can be improved, but to be honest, I don't have anything I'd like to see added or changed.

In terms of needed improvements, I don't have anything else to add, even small ones or nice-to-haves.

There are no improvements needed for EMQX that I haven't mentioned yet, even small ones.

I have been working as a cloud architect for three years in my current field.

EMQX is indeed stable.

In terms of scalability, EMQX is scalable.

The customer support experience has been positive because it has very good documentation, so I never need to contact someone.

I did not previously use a different solution; I started with EMQX.

I have seen a return on investment, particularly in terms of time saved.

My experience with EMQX regarding pricing, setup cost, and licensing shows that it is affordable.

Before choosing EMQX, I did not evaluate other options; I went straight with it.

EMQX has a good interface and control center, and it's better than standalone MQTT.

EMQX has a message queue management system, a dashboard, a control center, and some really useful debugging tools.

EMQX has positively impacted my organization because we didn't get any issues about MQTT; it just works.

This reliability has saved my team time and resources, as we don't spend time on debugging MQTT or the MQTT server; it just works and saves time.

The advice I would give to others looking into using EMQX is to try it with the cloud MQTT server, which is managed by the EMQX company.

I would rate this product a ten out of ten.

My main use case for EMQX is for my project to be controlled by phones and devices using the internet with the MQTT communication protocol. I use EMQX to control and monitor my project with multiple devices because EMQX allows users to grant control across many devices.

The best features of EMQX for me are that it is user-friendly, with a UI and dashboard that are easy to understand, allowing people to comprehend it quickly and finish their projects efficiently. There are many tutorials on YouTube and Google about EMQX that are clear and easy to understand, making it superior compared to other platforms.

EMQX has positively impacted my project because I received a good grade, which has been truly impactful for me, and it helped my project finish perfectly.

EMQX helped me complete my project perfectly because when I compared it to other platforms, EMQX truly fits my needs and my project, allowing me to explain my output more clearly to my lecturer, and ultimately I received a good grade, so it has been very helpful.

I am grateful because EMQX allows users to add not just one device but many devices, and it is a really compatible broker where I can implement my IoT device using EMQX perfectly with no delays.

I have not delved deep into the technical specifications of EMQX, but I believe it is already perfect for my needs.

I have been using EMQX for more than six months.

EMQX is really stable for me and for my project.

In my experience, EMQX's scalability is perfect, as I was using many devices and it works perfectly fine.

I have not used customer support for EMQX because I can understand it on my own by watching tutorials on YouTube, even if they are not from the official EMQX customer service, so I am satisfied with self-learning.

I cannot remember clearly if I used a different solution before EMQX, but I did use other solutions that did not satisfy me enough, so when I tried EMQX, I was satisfied and I continue to use it.

Before choosing EMQX, I evaluated other options and tried other software or platforms that did not satisfy me and did not suit my project, and when I tried EMQX, it suited my needs perfectly, so I chose to use it.

My advice for others looking into using EMQX is that when someone I know wants to try to build an IoT project, I will recommend them to use the MQTT protocol communication, which can be integrated with EMQX. I have no additional thoughts about EMQX before we conclude; it is perfect. I would rate this review a ten out of ten.