eProsima Fast DDS: a C++ DDS implementation for pub-sub systems
The most complete DDS - Proven: Plenty of success cases. Looking for commercial support? Contact [email protected]
At a glance
- What is it?
- Fast DDS is eProsima's C++ implementation of the OMG DDS standard and the RTPS wire protocol, and the default middleware for ROS 2 LTS releases. This review covers what it does, how the discovery and transport layers work, and where it is the wrong choice.
- Who is it for?
- Adopt Fast DDS if you are building a C++ distributed system that needs topic-based publish-subscribe over unreliable transports, or if you are already inside the ROS 2 ecosystem and want the middleware that ships with it. Do not adopt it if your team has no C++ build toolchain and no appetite for the DDS discovery model, or if a broker-based system such as MQTT already covers your message patterns.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Fast DDS solves, and who ends up using it
Distributed systems need processes on different machines to exchange typed data without a central broker becoming the bottleneck or the single point of failure. Fast DDS is a C++ implementation of the OMG Data Distribution Service standard, and it implements RTPS, the Real Time Publish Subscribe protocol that OMG maintains as the DDS wire interoperability protocol. The README describes RTPS as providing publisher-subscriber communications over unreliable transports such as UDP. That transport choice is the point: the library does not assume TCP, and it does not require a message broker in the middle.
The primary audience is C++ engineers building robotics, industrial, or embedded systems where nodes join and leave a network and must find each other automatically. The README lists plug and play connectivity, so that any new application is automatically discovered by other members of the network, as one of the main features. The second audience is the ROS 2 community. According to the README, Fast DDS is the default middleware for every ROS 2 long term support release and most of the non-LTS releases, which means a large number of people run it without choosing it.
Two API layers and a configurable transport stack
The architecture exposes two levels of control. The high-level Publisher-Subscriber API is the DDS-facing one, focused on usability. Below it sits a Writer-Reader API that the README describes as providing finer access to the inner workings of the RTPS protocol. In practice this means a team can write ordinary topic-based code and only drop to the lower layer when it needs to control protocol behaviour directly.
Communication policies are configurable per deployment. The README names best-effort and reliable publish-subscribe policies as configurable options for real-time applications, which matters because reliability has a cost: a reliable policy retransmits, a best-effort policy does not. The transport layer is described as interchangeable, so the protocol and system input/output channel combination can be selected for each deployment. Discovery is automatic rather than configured by hand, which is what makes the plug and play claim possible, and it is also the part of the system that most often surprises operators, because discovery traffic exists whether or not application data is flowing.
Installing Fast DDS and running the examples
The README does not carry a full install procedure inline. It points to the Fast DDS documentation for the complete installation guide, and states that you can either get a binary distribution or compile the library from source. Binary releases are obtained from the eProsima company website, not from a package index. The repository ships a colcon.pkg file and a fastdds.repos file at the top level, which is the layout ROS 2 developers will recognise, and examples live under examples/cpp/.
After building, the examples directory is the fastest way to see the two API layers in action. The README points to the Fast DDS Suite Docker image for a quick demonstration, and the documentation has a dedicated manual for that image. For tooling, the README links separate manuals for Fast DDS-Gen (the type generation tool) and the Fast DDS CLI. A first real use is therefore: generate types for your message with Fast DDS-Gen, write a publisher and a subscriber against the high-level API, and run both on the same host to confirm discovery. The README does not document a rollback procedure for a failed install, so plan to build in a clean workspace.
Where Fast DDS is the wrong tool
Fast DDS is C++. That is not a packaging detail, it is the adoption boundary. Teams without a C++ toolchain and a working CMake build will spend their first week on the build system rather than on messaging. The README lists a colcon.pkg and a CMakeLists.txt at the top level, and the examples are C++ under examples/cpp/, so there is no scripting-language entry point described in the README.
The second limitation is the discovery model itself. Automatic discovery is convenient on a small network and awkward on a large or segmented one. The README presents plug and play as a feature without discussing its traffic cost, and it does not document a discovery server configuration in the README, even though the documentation links a CLI manual. If your network has hundreds of participants or crosses subnets with restrictive multicast policy, verify the discovery configuration in the documentation before assuming the default works.
The third case is message semantics. DDS is topic-oriented pub-sub with quality-of-service policies. If your application is fundamentally request-response over a broker, or you need durable queues with per-message acknowledgement across a WAN, a broker-based system is a better fit and Fast DDS will feel like the wrong abstraction. The README does not claim to solve those problems.
How Fast DDS differs from Cyclone DDS and Zenoh
The closest comparison is Cyclone DDS, which is also a DDS implementation and also used in ROS 2. Both implement the same standard and the same RTPS wire protocol, so the difference is in implementation and configuration surface rather than in the programming model. Because both speak RTPS, interoperability between them is a property of the standard rather than of either project. Choosing between them usually comes down to which one your platform support matrix covers and which configuration model your team can operate.
Zenoh is a different kind of comparison, because it is not a DDS implementation. It is a pub-sub and query protocol with its own routing approach, and it does not carry the DDS API or the RTPS wire protocol. If you need DDS-standard interoperability with other vendors' implementations, Zenoh is not a substitute. If you need a lightweight pub-sub layer and do not care about DDS conformance, the DDS API surface in Fast DDS is more than you need.
OpenDDS is the other DDS implementation worth naming. It is a DDS implementation in C++ as well, so the same standard applies, and again the practical difference is build system, platform support and configuration ergonomics rather than protocol behaviour.
Maintenance, versioning and licence
The repository is not archived and the last push was on 2026-09-23. Three releases appear in the recent list: v2.14.7 on 2026-09-08, v2.6.12 on 2026-07-23, and v3.2.5 on 2026-07-22. That pattern is worth reading carefully. v2.6.x is still receiving patch releases, which indicates a maintained older line, and v3.2.5 shows the newer major line is also active. Two supported lines means upgrade planning is a real task, not a formality. The repository carries VERSIONING.md, UPGRADING.md and RELEASE_SUPPORT.md at the top level, so the project documents its own policy; read those three files before pinning a version, because the README does not state how long each line is supported.
The licence is Apache-2.0. That is a permissive licence, and it is the same licence family used broadly in this space. This is not legal advice: if you redistribute Fast DDS inside a product, or link it in a way you are unsure about, check the terms with your own counsel. The README also advertises commercial support at [email protected], which is a separate offering from the open source licence and does not change it.
Upgrade cost is dominated by the two-line situation. A team on v2.6.x that wants features from v3.2.x has to cross a major version boundary, and the presence of UPGRADING.md suggests the project expects that crossing to need guidance. Budget for it rather than assuming a drop-in replacement.
Editorial conclusion
Adopt Fast DDS if you are building a C++ distributed system that needs topic-based publish-subscribe over unreliable transports, or if you are already inside the ROS 2 ecosystem and want the middleware that ships with it. Do not adopt it if your team has no C++ build toolchain and no appetite for the DDS discovery model, or if a broker-based system such as MQTT already covers your message patterns. Before committing, read PLATFORM_SUPPORT.md for your target OS, check the release notes for the version line you intend to pin, and confirm whether the Apache-2.0 licence on the core covers the deployment you have in mind.
Frequently asked questions
Is Fast DDS open source?
Yes. The repository is licensed under Apache-2.0, and the README links the licence badge to the Open Source Initiative page for that licence. Commercial support is offered separately by eProsima.
How does Fast DDS work?
It implements the OMG DDS standard and the RTPS protocol, providing publisher-subscriber communication over transports such as UDP. Applications use either a high-level Publisher-Subscriber API or a lower-level Writer-Reader API that exposes more of the RTPS internals.
How do I install Fast DDS?
The README says you can get a binary distribution or compile from source, and refers to the Fast DDS documentation for the complete installation guide. Binary releases are obtained from the eProsima website.
What is Fast DDS used for?
It is used for publish-subscribe communication between distributed applications, including real-time systems. The README names robotics as a major case, with ROS 2 using it as the default middleware for its LTS releases.
How does Fast DDS compare with Cyclone DDS?
Both are DDS implementations that use the RTPS wire protocol, so the difference is in implementation and configuration rather than in the programming model. The README does not provide a performance comparison between them.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/eprosima-fast-dds)