Pico W vs Pico 2 W for MQTT: RP2040 vs RP2350 Performance, Memory and TLS

Pico W vs Pico 2 W is a short decision for most MQTT projects, but the reasons behind it are worth understanding before you buy a drawer full of boards. Both have the same footprint, the same pinout and the same Infineon CYW43439 Wi-Fi chip; the difference is the microcontroller. This comparison explains what the move from RP2040 to RP2350 changes for connected devices, especially memory and TLS, and gives you a small script to measure the difference on your own network.

The Short Answer

For new MQTT designs, choose the Pico 2 W. It has roughly double the RAM and flash, faster Cortex-M33 cores with a floating-point unit, and hardware security features, while running the same MicroPython code as the Pico W with almost no changes. Keep using the Pico W where you already have stock, a validated design, or a very simple sensor that publishes over plain MQTT on a trusted network, where the extra headroom brings little benefit.

Pico W vs Pico 2 W Specifications

The headline numbers are from Raspberry Pi's published datasheets; check the official Pico documentation for the full details and current errata.

What the Differences Mean for MQTT Devices

Wi-Fi is the same

Because both boards use the CYW43439 over the same SPI-style interface, raw Wi-Fi range, supported bands (2.4 GHz only) and network throughput are essentially identical. A Pico 2 W will not connect from further away or to a 5 GHz network. If your MQTT problems are about signal strength, a new board will not fix them; antenna placement and access point position will.

Memory headroom is the biggest practical win

On a Pico W running MicroPython, available heap after boot is comfortable for plain MQTT but gets tight once you add TLS, JSON handling, a few sensor drivers and buffered readings. A TLS session alone needs tens of kilobytes for its buffers, and fragmentation can cause ENOMEM errors even when the total free memory looks sufficient.

The Pico 2 W roughly doubles the SRAM. In practice that means:

• TLS connections that fail intermittently with memory errors on a Pico W usually just work.
• You can buffer more readings while offline and publish them when the broker is reachable again.
• Larger JSON payloads and more topics per device are less of a concern.

Flash doubles too, from 2 MB to 4 MB, which leaves more room for MicroPython libraries, certificate files, logs and over-the-air update schemes.

TLS handshake time

On the RP2040, every TLS handshake runs entirely in software on Cortex-M0+ cores, which lack the instructions that make big-number arithmetic fast. The handshake is clearly noticeable, and on a battery device that reconnects each time it wakes, it is a real cost in time and energy.

The RP2350's Cortex-M33 cores run at a higher clock, execute more efficiently per cycle and include DSP instructions, so the public-key operations in the handshake complete faster. The RP2350 also has a SHA-256 accelerator and a true random number generator. Whether your firmware uses the SHA-256 hardware depends on how the TLS library is built, but the CPU improvement alone makes handshakes shorter. Rather than trusting someone else's numbers, measure on your own network with the script below.

Security features

The Pico W has no secure boot or protected key storage, so anyone with physical access can read the flash, including Wi-Fi passwords and MQTT credentials. The Pico 2 W adds signed boot and one-time-programmable memory that can hold keys, plus Arm TrustZone for separating trusted code. These features take deliberate setup through the C SDK and are not switched on by MicroPython by default, but they make a real difference for products deployed where devices can be stolen or tampered with.

Software compatibility

Your Pico W MicroPython code almost always runs unchanged on the Pico 2 W after flashing the RPI_PICO2_W firmware. The network, machine.Pin("LED"), umqtt.simple and ssl APIs are the same. For the internal temperature sensor, use machine.ADC(machine.ADC.CORE_TEMP) instead of a hard-coded channel number to stay portable. The C/C++ SDK 2.x and the Arduino-Pico core support both chips.

One hardware note: early RP2350 silicon had a documented erratum (E9) affecting GPIO inputs that rely on internal pull-down resistors. Later chip revisions address it. If your design depends on internal pull-downs, read the current RP2350 datasheet errata and use external resistors where advised.

Benchmark Both Boards Yourself

This MicroPython script runs on either board. It reports the CPU frequency, free memory, and the time for a plain MQTT connect and a TLS MQTT connect to broker.connectmq.com. Copy isrgrootx1.der to the board first, as described in our Pico W MQTT TLS guide.

# bench.py - compare MQTT connect times on Pico W and Pico 2 W
import time, gc, ssl, network, machine, os, ubinascii
from umqtt.simple import MQTTClient

WIFI_SSID = "YOUR_WIFI_SSID"
WIFI_PASSWORD = "YOUR_WIFI_PASSWORD"
BROKER = "broker.connectmq.com"
CID = "bench-" + ubinascii.hexlify(machine.unique_id()).decode()
RUNS = 5

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(WIFI_SSID, WIFI_PASSWORD)
while not wlan.isconnected():
    time.sleep(0.2)

print("Board:", os.uname().machine)
print("CPU freq:", machine.freq() // 1_000_000, "MHz")
gc.collect()
print("Free heap:", gc.mem_free(), "bytes")
print("RSSI:", wlan.status("rssi"), "dBm")

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.verify_mode = ssl.CERT_REQUIRED
with open("isrgrootx1.der", "rb") as f:
    ctx.load_verify_locations(cadata=f.read())


def timed_connect(port, use_tls):
    gc.collect()
    c = MQTTClient(CID, BROKER, port=port, keepalive=30, ssl=ctx if use_tls else None)
    t0 = time.ticks_ms()
    c.connect()
    dt = time.ticks_diff(time.ticks_ms(), t0)
    c.publish("connectmq/demo/bn4q7d/bench", "%s %d" % ("tls" if use_tls else "tcp", dt))
    c.disconnect()
    return dt


for label, port, tls in (("Plain TCP 1883", 1883, False), ("TLS 8883", 8883, True)):
    times = []
    for _ in range(RUNS):
        times.append(timed_connect(port, tls))
        time.sleep(1)
    times.sort()
    print(label, "connect ms - min:", times[0], "median:", times[len(times) // 2], "max:", times[-1])

Run it on both boards on the same network, at the same spot, and compare the medians. The plain TCP numbers show your network baseline; the difference between TCP and TLS shows the cryptographic cost on each chip. The script publishes each result to the public MQTT test broker too, so you can watch both boards report side by side:

mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-bn4q7d -v -t "connectmq/demo/bn4q7d/#"

Keep the run count modest. The public broker allows 10 messages per second per client, and repeated rapid reconnects are not a realistic workload anyway.

Which Board for Which MQTT Project

The last row is a reminder that the Pico family is not the only option. Our ESP32 vs Raspberry Pi Pico W comparison covers when an ESP32 is the better fit, and the Pico W battery MQTT guide goes deeper into power budgets.

Connecting Either Board to a Production Broker

Whichever board you choose, the broker side is the same. For testing, use broker.connectmq.com anonymously with a unique client ID. For real deployments, create a private broker on ConnectMQ and use the generated username, password and client ID over TLS on port 8883. The Let's Encrypt certificate means the same root certificate file works on both boards. The step-by-step code for a first connection is in our Raspberry Pi Pico W MQTT tutorial, and the broader Raspberry Pi MQTT tutorial covers the full-size boards that often act as gateways next to Pico devices.

A managed MQTT broker takes care of uptime, certificates and connection limits, so your effort goes into the device firmware. On the free ConnectMQ Serverless plan you get up to 25 connections, QoS up to 1 and messages up to 256 KB, which is plenty for a fleet of Pico boards in development.

Connect Your Pico Boards to ConnectMQ

Sign up at app.connectmq.com for the free Serverless plan, no credit card required. Create a broker, flash either board with the matching MicroPython build, and use the portal's live topic explorer to watch your Pico W and Pico 2 W report in real time.

Frequently Asked Questions

Is the Pico 2 W compatible with Pico W code?

Mostly yes. After flashing the RPI_PICO2_W MicroPython build, Wi-Fi, GPIO, umqtt.simple and TLS code run unchanged. Use machine.ADC(machine.ADC.CORE_TEMP) for the internal temperature sensor to stay portable.

Does the Pico 2 W have better Wi-Fi than the Pico W?

No. Both use the same CYW43439 chip with 2.4 GHz Wi-Fi and Bluetooth 5.2, so range and throughput are essentially the same. The improvements are in the microcontroller.

Is TLS faster on the Pico 2 W?

Yes, the RP2350's Cortex-M33 cores complete the handshake faster than the RP2040's Cortex-M0+ cores. Run the benchmark script in this article on both boards to see the difference on your network.

Should I upgrade an existing Pico W project?

Only if you are hitting memory limits, need faster reconnects with TLS, or need secure boot. A working Pico W design on a trusted network has little to gain from switching.