MongoDB Atlas Stream Processing remains one of the easiest ways to work with streaming data, simplifying near real-time data transformation and integration. This enables developers to use the power of the MongoDB aggregation framework to process data streams from sources like Apache Kafka that drive event-driven applications. To make stream processing even more accessible and cost-effective, we recently introduced workspaces and new processor tiers, providing clearer pricing, more granular control, and faster paths to production.
What’s new
Workspaces, now replacing instances
Workspaces have replaced stream processing instances (SPIs) as the organizational model for MongoDB Atlas Stream Processing. While workspaces still serve as logical containers for managing processors, configuring connections, and monitoring your environment, the resource tiers are now defined per processor, not per workspace. This gives you granular control to match resources to specific workload requirements.
You can set default tiers for your workspace, and then adjust individual processors as needed, gaining the flexibility to right-size specific workloads.
New tiers for better workload matching
To provide this flexibility, MongoDB Atlas Stream Processing now offers expanded processor tiers, providing more granular options for matching resources to workload requirements. The available tiers include SP2 and SP5 for development, SP10 and SP30 for moderate to intensive processing, and SP50 for high-traffic and resource-intensive operations.
*SP10 and SP30 already existed, but now have new specifications.
These tiers let you optimize for both performance and cost. A processor handling lightweight operations can run on SP5, while a complex aggregation pipeline can scale up to SP50, all within the same workspace.
Per-processor pricing
With multiple tiers available, MongoDB Atlas Stream Processing workspaces introduce a new per-processor pricing model where you’re billed only for the processors you use while they’re running. Each stream processor runs independently with isolated resources, so you can pay for exactly what you need.
How it works
When you’re creating or starting a stream processor, you can specify a tier directly in the start command (e.g., sp.myProcessor.start({"tier": "SP30"})). If you don’t specify a tier, the processor uses the workspace’s default tier. This enables you to set sensible defaults while enabling you to customize specific processors based on their requirements.
For example, if most of your processors handle moderate workloads, you can set SP10 as the workspace default. Then, if you add a processor running intensive aggregations in that same workspace, you can specify SP30 at runtime to increase resources for that individual processor. The workspace provides the organizational structure while tiers handle resource allocation.
This simplifies development by enabling you to test on a lower tier, then scale up to handle production workloads with a single command, all without needing to change the underlying processor.
How to get started with workspaces
MongoDB Atlas Stream Processing workspaces and additional processor tiers give you the control and flexibility to build near real-time applications that scale efficiently. With clear pricing, granular resource options, and simplified management, you can focus on building event-driven architectures without the overhead of complex infrastructure decisions.
Workspaces are accessible to all MongoDB Atlas Stream Processing users. All existing stream processing instances have been automatically converted to the new model with no service interruption.
Next Steps
For more information on configuring workspaces, setting default tiers, and selecting processor sizes, visit the MongoDB Atlas Stream Processing documentation.