Choosing an RPC: Where the Free Tier Hits the Wall

The Moment the Free Tier Stops Being Free

I start the bot. Within a few minutes the logs are flooded with the same three digits over and over again: 429, 429, 429. The chain is fine. The validators are humming. The problem is the doorway between my code and the network, and that doorway is slamming shut on me every few seconds.

This is the part of building an MEV bot that nobody warns you about in a tutorial. You can read every paper on AMM math, you can pre-compute every cycle, you can build the slickest transaction packer on Earth — but if the pipe you use to talk to the chain is the same pipe a thousand other people are squeezing through, you have already lost the race before you noticed it started.

Why the Public Endpoint Exists in the First Place

When I first wired up the bot, I pointed it at the public endpoint listed in the official Solana docs. It felt almost rude not to. The address is right there, it works on day one, it costs nothing, and it speaks the same JSON-RPC dialect as every paid provider on the market. For poking around, building a wallet, or running a tutorial, it is genuinely fine.

But the documentation itself is not subtle about who it is for. According to the official Solana cluster documentation, the public endpoints are explicitly "not intended for production applications," and the docs tell you, in plain English, to "use dedicated/private RPC servers when you launch your application, drop NFTs, etc." That sentence is sitting at the top of the page like a warning sign at the entrance to a construction site. I read it, nodded, and walked in anyway.

The limits, again from the official docs, are precise: 100 requests per 10 seconds per IP across the whole endpoint, 40 requests per 10 seconds per IP for any single method, 40 concurrent connections per IP, and a cap of 100 MB of data every 30 seconds. The error you get when you cross one of those lines is the friendly little HTTP 429, sometimes joined by a 403 if the gateway decides you are not just noisy but a problem.

Doing the Tenth-Grade Math

There is a moment in every engineer's career where you realize a number you accepted casually is actually telling you the whole story. For me, it was the moment I divided 100 by 10.

One hundred requests per ten seconds is ten requests per second. Ten. That is the upper bound of what the public endpoint will let me do, in total, for every method I might ever want to call. I am not talking about peak traffic or burst capacity. I am talking about the steady-state ceiling.

My bot, doing the most boring possible thing on a quiet day, comfortably wants several hundred requests per second just to keep its picture of the world from going stale. Every pool I am watching needs an account read. Every quote update wants a recheck. Every candidate transaction wants a simulation. Every confirmation wants a status lookup. Ten per second is not a budget; it is a joke at my expense.

And that is before the second problem kicks in.

The Noisy Neighbor I Cannot See

The first time I got rate-limited at what felt like an absurdly low request rate, I assumed I had a bug. I added logging, counted my outbound calls, and confirmed I was nowhere near my supposed budget. The 429s kept coming anyway.

It took reading a piece of post-mortem writing — a debugging walkthrough on exactly this problem — for the model to click. As that analysis puts it, "A 429 error in Solana development is almost never a protocol-level error but a gateway error. It means your RPC provider has intercepted your request and decided not to forward it to the Solana cluster." The chain is not refusing me. The gateway in front of the chain is.

And here is the part that quietly broke my brain: when one user on a shared gateway misbehaves, the load balancer does not just rate-limit that user. According to the same analysis, it tightens limits across the node, which means other developers — me, in this case — get throttled because of activity that has nothing to do with us. One debugging write-up even uses a sniper bot scanning for new liquidity pools as the textbook example of this kind of noisy neighbor.

This is the kind of thing that does not show up in benchmarks. On a quiet Tuesday at 3 a.m., the public endpoint feels snappy. During a meme coin launch on a Friday night, the same endpoint can feel like a government service counter at 4:55 p.m. on a Friday. Same building, same staff, same posted rules — completely different experience depending on who else walked in.

The Credit Trap Hiding in getProgramAccounts

Once you move from the public endpoint to a free tier on a managed provider, the units of throttling change. Instead of raw requests per second, you typically get a monthly bucket of "credits" or "compute units," and each method costs a different number of them.

The published write-up I keep coming back to lays the disparities out: a getBalance call might cost one credit, while sendTransaction and getProgramAccounts can cost ten times that. That ten-to-one ratio looks innocent until you remember that getProgramAccounts is the call you reach for whenever you want to scan all the accounts owned by a specific program — like, say, every pool a particular DEX has ever opened.

The arithmetic is sobering: polling getProgramAccounts once per second adds up to roughly 864,000 credits per day. Most free tiers in this corner of the market are sized in the single-digit millions of credits per month. The article's blunt summary — that "doing this in a tight loop is the fastest way to get IP banned" — is not hyperbole. You can drain a month of free quota in a long afternoon.

The thing that makes this especially nasty is that getProgramAccounts is exactly the call a naive bot wants to make. You are trying to discover and track pools; this is the method that lists them. You hit it not because you are being greedy but because the API surface invites you to. The free tier is generous in credits the way an all-you-can-eat buffet is generous in calories — you can technically have anything, but order the wrong dish twelve times and you will not last the hour.

There are technical mitigations, of course. Guidance on common RPC errors recommends swapping getProgramAccounts for newer versioned variants where available, batching individual calls, caching anything that does not change every slot, and moving from HTTP polling to WebSocket subscriptions where the data is naturally push-shaped. Every one of those changes helps. None of them changes the fundamental fact that a free tier is sized for development, not for combat.

What MEV Actually Demands

If I step back and ask what an MEV bot needs from its RPC, the answer is not a single number. It is a stack of them, and most of them are an order of magnitude larger than what any free tier provides.

An industry analysis on Solana RPC providers for MEV is the clearest articulation I have seen. They argue, in their analysis of the competitive landscape, that a serious bot needs "sub-50ms latency for reading account state and submitting transactions" with P99 numbers in the same neighborhood as the median. They describe roughly 140 ms latency as "solid for most arbitrage and liquidation strategies, though not in the sub-50ms tier for ultra-HFT," which is a polite way of saying that anything slower is fine for hobby projects and not for competitive ones.

On throughput, the same piece pegs standard paid tiers at around 400 requests per second — "adequate for most bots but can become a constraint for very high-frequency operations" — and notes that the most aggressive operators want capacity stretching toward 5,000 requests per second.

If I lay those numbers side by side with what the public endpoint offers, the ratio is not subtle. Ten requests per second versus four hundred is a 40× gap. Ten versus five thousand is a 500× gap. That is not the kind of distance you close with cleverer caching. It is the kind of distance you close by buying a different ticket.

Latency Is the Quiet Killer

Throughput is the easy thing to talk about because it is one number. Latency is the harder thing because it is a distribution, and the part that matters is the part that does not show up in averages.

A comparison of shared vs dedicated Solana RPC nodes captures the failure mode well. On shared infrastructure, the analysis notes, "median latency may look acceptable while your 95th and 99th percentile numbers tell a different story." That gap is where MEV bots get killed. You can be in fine shape for ninety-five out of every hundred requests and still get beaten on the five that actually matter, because the requests that matter most are usually the ones submitted in the loudest moments, which is exactly when shared infrastructure misbehaves.

The same comparison describes dedicated infrastructure as the mirror image: "all hardware is yours. There is no contention from other users, which means performance under load behaves the same as performance at idle." That sentence is doing more work than it appears. The whole promise of dedicated infrastructure for MEV is not raw speed; it is that speed remains the same when it counts.

The MEV-focused analyses go further. A 2026 trading bot infrastructure guide is uncompromising on this point: "If your bot reads pool modifications, swap instructions, or token listings from public RPC endpoints, you've already lost." The reason, they argue, is that shared infrastructure experiences "filtering, rate limiting, and de-prioritization during congestion" — exactly the conditions under which MEV opportunities show up. The moment the world gets interesting is the moment shared infrastructure becomes the least useful version of itself.

The Streaming Question

There is also the question of how data even arrives. The default mental model is request-response: I ask the node a question, it answers, I ask another. That model is fine for a wallet refresh button. It is fundamentally wrong for a bot that wants to know about state changes the moment they happen.

Multiple infrastructure write-ups stress that competitive bots use streaming protocols rather than polling. Each protocol has different characteristics — some emphasize fan-out, some emphasize tight typing, some emphasize how close they sit to the validator's internal data path — and the right answer depends on what you are trying to listen for. The point I take away is not which protocol to use. It is that polling a public HTTP endpoint, no matter how fast you poll it, will never put you in the same conversation as a system that subscribes to events as they happen. They are different sports.

Free tiers, almost universally, do not include the streaming surface. You can sometimes get a basic WebSocket subscription on a free tier, but the more competitive feeds are reserved for paying customers, and often for paying customers above a certain plan. This is not an accident of pricing; the infrastructure required to fan out real-time chain data is genuinely expensive, and free customers do not get to use it because it would not survive contact with even moderate demand.

The Honest Economics

So what do you do? The cheap intuition is "just run your own node." The harder truth, laid out in an analysis of the Solana RPC dilemma, is that self-hosting a Solana RPC is closer to running a small data center than running a Raspberry Pi.

The article lays out the requirements: hundreds of gigabytes of RAM, multiple terabytes of NVMe storage, hardware investments measured in thousands of dollars, monthly bandwidth budgets that look more like a small ISP than a hobby project, and an on-call rotation of engineers willing to wake up at 3 a.m. when a snapshot job fails. The break-even point against managed providers, the same analysis estimates, lives somewhere in the range of one to two billion monthly requests. If you are nowhere near those volumes — and almost no individual bot operator is — self-hosting is paying full retail to learn lessons that other people have already learned.

The practical answer for someone in my position is more boring than self-hosting and less embarrassing than shared free tier: a paid plan, probably starting modestly, with the explicit understanding that the bill is going to grow as the bot does. "Free" is fine for the day you write your first hello-world script. It is not the configuration in which you make money.

And that is the framing shift, really. The free tier is not a starter plan for production. It is a sandbox for learning. Treating it as a starter plan is the same kind of category error as treating a gym membership trial as a serious training regimen. The trial exists to let you confirm the equipment works. It does not exist to get you to the Olympics.

The Three Walls

If I had to summarize the lessons of the past few weeks into the shape of a sign I would hang above my desk, it would be a list of the three walls that the free tier hits, in order:

The first wall is the rate limit. Ten requests per second on the public endpoint, and not much more on most free managed tiers, simply does not fit the shape of a bot that wants to track even a modest number of pools.

The second wall is the noisy neighbor. Even when your own usage is well below the posted limit, somebody else's spike can pull the rug out from under you, and you have no visibility into who they are or when they will show up again.

The third wall is latency, and specifically the tail. The median can look healthy on a quiet day and lie to you about how the system behaves on a loud one. The bot that wins is the one whose worst day looks like its best day, and that property is something you essentially have to buy.

None of these walls are about Solana itself being slow or unreliable. The protocol is doing its job. The walls all live in the strip of infrastructure between my code and the chain — the strip I was previously treating as a free utility and am now starting to treat as the most important line item in the project budget after my own time.

Where That Leaves Me Right Now

I do not have a clean answer yet for the question of which paid plan to land on. The pricing pages all look like they were laid out by the same person who designs cellphone contracts, and the units of measurement — credits, compute units, requests, methods — vary enough between providers that direct comparisons are mostly fiction. Several infrastructure providers offer broadly similar shapes of plan with very different fine print, and I expect the honest way through that maze is to read carefully, ask uncomfortable questions about P99 latency, and be willing to switch.

What I do know is what I am no longer willing to do. I am not willing to point a serious bot at a public endpoint and pretend the throughput numbers will average out in my favor. I am not willing to confuse a free tier with a starter plan. And I am not willing to design around the assumption that the gateway is free of contention, because the contention is precisely what the gateway is for.

The chain is the cheap part. The seat next to the chain is what costs money. That is the bill I have to pay if I want to keep playing.

Key Takeaways

• Solana's public RPC endpoint is explicitly not for production, with the official docs capping it at 100 requests per 10 seconds per IP and warning that the limits can change without notice.
• A 429 error on Solana is almost always a gateway decision by the RPC provider, not a protocol-level event, which is why noisy neighbors on shared infrastructure can throttle you even when your own usage is modest.
• Free tiers can be drained in hours by naive polling patterns, because high-cost methods like getProgramAccounts consume credits roughly an order of magnitude faster than light reads.
• Competitive MEV operations target sub-50ms latency and request rates that can stretch into the thousands per second — gaps of 40× to 500× over what free tiers provide.
• Self-hosting only pencils out at very large monthly request volumes; for most operators the realistic path is a paid managed plan, chosen with serious attention to P99 latency and streaming support rather than headline price.