If Postman shows up as one of the heavier processes in Activity Monitor even during what feels like light API testing, that's a documented, recurring complaint rather than a sign your setup is misconfigured.
Why an API testing tool needs this much memory
Postman is built on Electron, the same Chromium-and-Node.js framework behind Slack, Discord, and many other modern desktop apps, which brings its own baseline memory overhead before you've even made a single API request. On top of that, Postman maintains request history, saved collections, environment variables, and response bodies (which can be large if you're testing endpoints that return substantial JSON or binary data) all in active memory for quick access, rather than reading them from disk each time you switch between saved requests.
What the real complaint history shows
Postman's own GitHub issue tracker has multiple threads spanning years describing high memory consumption, including reports of virtual memory hitting 20GB and one issue specifically titled around Postman consuming excessive memory on Mac. The recurrence of this complaint across different Postman versions suggests it's a persistent characteristic of the app's architecture and how it manages collections and history, rather than a single bug that gets fixed and reappears.
What genuinely helps
Clear old request history periodically. Postman's History tab accumulates every request you've made. Under Settings, you can configure how much history is retained, or clear it manually; a smaller history reduces what Postman keeps readily accessible in memory.
Archive or remove large saved collections you no longer use. Collections with many saved requests and large example responses add up. Exporting old collections you rarely reference and removing them from your active workspace reduces Postman's working set.
Close response tabs you're not actively reviewing. Each open response tab, particularly for large JSON or binary payloads, holds that data in memory. Closing tabs for requests you've already reviewed is a quick way to reduce active memory use during a long testing session.
Restart Postman periodically during heavy use. As with other Electron apps, a full restart clears whatever has accumulated during a long session more thoroughly than any in-app cleanup option.
Is there a lighter alternative?
If Postman's memory footprint is a recurring frustration and you don't need its full collaborative and collection-management feature set, command-line tools like curl or lighter GUI alternatives such as Insomnia or Bruno (which markets itself specifically on a lighter footprint) are worth considering for simpler API testing needs. This is a genuine trade-off against Postman's more extensive team and workspace features, not a strict downgrade.
Where a memory-relief tool fits in
Postman's own accumulated history and cached responses need Postman itself restarted or cleaned up to release fully. What Shiny helps with is everything else competing for memory on a developer's Mac alongside Postman: browser tabs, Docker, your code editor, and other tools all running simultaneously during a typical API development workflow. Freeing that up in one click gives Postman, and everything else, more headroom without needing to interrupt your testing session.
For other parts of a typical developer's memory picture, see the Docker Desktop memory guide and the Cursor memory guide.
Workspaces and collections: the feature driving the memory cost
Postman's evolution from a simple request-testing tool into a full API platform with team workspaces, shared collections, mock servers, and API documentation generation is directly responsible for much of its current memory footprint compared to earlier, simpler versions. Each of these features means Postman is doing more in the background even when you're not actively using them: syncing workspace changes, maintaining collection version history, and keeping documentation previews ready to render. If your use case is genuinely simple (testing a handful of endpoints solo, no team workspace, no shared collections), you're paying the memory cost of infrastructure built for a much larger, collaborative use case that you may not need.
A practical audit if memory keeps climbing during a work day
Before assuming Postman itself is simply "heavy" and moving on, it's worth a quick check of exactly what's accumulated in your specific workspace: how many collections do you have loaded, how much request history has built up, and are you keeping response tabs open from earlier in the day without realising it. Postman's own Settings panel under General shows some of this, and a workspace that's been actively used for months without any cleanup will naturally carry more overhead than a fresh one. This audit takes a few minutes and often explains a meaningful chunk of the difference between a "normal" memory footprint and the more extreme figures reported in the complaint threads above, and it's worth repeating every few weeks rather than treating as a one-time fix, since both collections and history naturally build back up again over continued use, making this less a one-time fix than an ongoing part of keeping a heavily used Postman workspace running smoothly.