When you're testing a Solana application, the RPC provider subscription plan you pick can shape how fast you iterate and how realistic your results are. A plan that's too small stalls your test suite with rate limit errors; one that's too large wastes budget on capacity you never use. This article walks through the plan features that matter for testing, how to match a plan to your testing stage, and what to check before you subscribe.
Quick recommendation: match the plan to your testing stage
Before comparing providers, decide what kind of testing you're doing. That decision narrows down which plan features you actually need.
- Prototyping and unit tests: A free or low-cost shared plan with access to Solana devnet is usually enough. You need basic JSON-RPC methods and a WebSocket endpoint for account subscriptions.
- Integration testing against mainnet: You'll want a paid shared plan with higher request allowances and consistent performance, because devnet behavior can differ from mainnet.
- Load testing or performance benchmarking: A dedicated node or a plan with high rate limits is safer. Shared plans may throttle you during bursts, which skews your results.
If your testing is mostly on devnet, check that the provider actually offers a devnet endpoint. Some providers only expose mainnet on paid tiers, which forces you to pay for mainnet capacity you don't need yet. OnFinality, for example, provides a public Solana devnet endpoint and a mainnet endpoint, so you can start testing without a paid plan and upgrade when your traffic grows.
What a subscription plan for testing should include
Not all Solana RPC plans are created equal. Here are the features to compare when you're evaluating a plan for testing purposes.
Request limits and rate limiting
Every shared RPC plan has a request allowance, usually measured in requests per second (RPS) or monthly credits. For testing, the key question is: what happens when you exceed the limit?
- Does the provider return HTTP 429 errors, or does it queue requests?
- Is the limit per second, per day, or per month?
- Can you temporarily increase the limit for a load test?
A plan with a low RPS cap might be fine for unit tests but will block you during a load test. Look for a plan that lets you monitor your usage so you know when you're close to the limit.
Devnet and testnet access
Solana has several test environments: devnet, testnet, and localnet. Devnet is the most common for application testing because it's a public cluster with a faucet for SOL. Check that the provider's subscription includes access to the devnet endpoint, and whether that access counts against the same request allowance as mainnet.
Some providers treat devnet as a separate product with its own limits. Others include it in the same plan. If you're testing heavily on devnet, you want a plan that doesn't drain your mainnet quota.
WebSocket support
Many Solana apps subscribe to account or program changes via WebSocket. If your testing involves real-time updates, you need a plan that supports WebSocket connections. Check:
- How many concurrent WebSocket connections are allowed?
- Is there a separate charge for WebSocket usage?
- Are WebSocket subscriptions stable during long test runs?
A plan that only offers HTTP JSON-RPC may not be enough for testing dApps that rely on live updates.
Archive data and historical access
Some tests need to replay historical states or query old account data. That requires an archive node. Not all providers offer archive data on every plan. If your testing involves historical analysis or debugging past transactions, confirm the plan includes archive access.
Geographic coverage and latency
Latency matters even in testing, especially if you're measuring performance. A provider with endpoints in multiple regions can reduce round-trip time. For basic functional testing, latency is less critical, but for load testing, a nearby endpoint gives you more accurate throughput numbers.
Comparing Solana RPC providers for testing
The table below summarizes what to compare across providers when you're choosing a subscription plan for testing. Use it as a checklist when you evaluate options.
| Feature | What to check | Why it matters for testing |
|---|---|---|
| Devnet access | Is devnet included? Separate quota? | Avoid paying for mainnet when you only need devnet |
| Request limits | RPS cap, monthly credits, burst policy | Prevent 429 errors during test runs |
| WebSocket support | Concurrent connections, stability | Needed for real-time subscription tests |
| Archive data | Available on plan? Extra cost? | Required for historical state replay |
| Rate limit monitoring | Usage dashboard, alerts | Know when you're approaching limits |
| Geographic endpoints | Regions offered | Reduce latency for load tests |
| Free tier | Exists? What limits? | Start prototyping without cost |
When you compare providers, put your own testing workload first. A provider that excels at mainnet production traffic might not have the devnet flexibility you need for testing.
How to test a provider before you commit
Most providers offer a free tier or a trial period. Use that time to run a structured evaluation rather than just a few curl commands. Here's a practical approach:
-
Create a test script that exercises the methods your app uses most, such as
getBalance,getLatestBlockhash, andsendTransaction. - Run the script against the devnet endpoint for a few hours to see if you hit rate limits.
- Test WebSocket subscriptions by subscribing to an account and keeping the connection open for an extended period.
- Measure latency from your development environment to the endpoint.
- Check the provider's documentation for any testing-specific guidance or limits.
Here's a simple JavaScript example using the Solana web3.js library to test a basic RPC call:
const { Connection, clusterApiUrl } = require('@solana/web3.js');
// Replace with your provider's devnet endpoint
const endpoint = 'https://solana.api.onfinality.io/public';
const connection = new Connection(endpoint, 'confirmed');
async function testConnection() {
try {
const version = await connection.getVersion();
console.log('Solana node version:', version);
const slot = await connection.getSlot();
console.log('Current slot:', slot);
} catch (error) {
console.error('RPC test failed:', error);
}
}
testConnection();
Note: The public endpoint in the example is for mainnet. For devnet testing, use the provider's devnet URL, which you can find on their network page. OnFinality's Solana devnet page lists the correct endpoint.
Common pitfalls when testing with a subscription plan
Even with a good plan, you can run into issues that waste time. Here are common pitfalls and how to avoid them.
Pitfall 1: Using mainnet for tests that should run on devnet
If your tests don't need real funds or mainnet state, use devnet. It's free and doesn't consume your mainnet quota. Some providers offer a separate devnet endpoint that you can use without a paid plan.
Pitfall 2: Ignoring WebSocket connection limits
If your app opens many WebSocket connections, you might hit the provider's limit during testing. Check the plan's WebSocket policy before you write tests that rely on dozens of subscriptions.
Pitfall 3: Not monitoring rate limit headers
Many providers include rate limit information in HTTP response headers. If you ignore them, you won't know you're about to be throttled. Add logging to your test client to capture these headers.
Pitfall 4: Assuming devnet and mainnet behave identically
Devnet can have different validator versions or congestion levels than mainnet. If your test results are inconsistent, check whether the issue is network-specific rather than a bug in your code.
How to scale your plan as testing grows
Your testing needs will change as your project matures. Here's a typical progression:
- Start with a free tier to validate your app's basic functionality on devnet.
- Upgrade to a paid shared plan when you need higher rate limits or mainnet access for integration tests.
- Consider a dedicated node when you run load tests or need consistent performance for benchmarking.
A dedicated node gives you full control over the RPC endpoint and eliminates contention from other users. It's also useful if you need to test custom configurations or run your own indexer. OnFinality offers dedicated nodes that you can provision for Solana, and you can manage them through the same dashboard as your shared RPC endpoints.
When you upgrade, review your actual usage metrics first. If you're only using 10% of your current plan's allowance, a bigger plan might be premature. But if you're hitting rate limits during routine tests, it's time to move up.
Key Takeaways
- Match your subscription plan to your testing stage: free tier for prototyping, paid shared for integration, dedicated for load testing.
- Check devnet access, WebSocket limits, and archive data availability before subscribing.
- Use the provider's trial period to run a structured test of the methods and connection types your app uses.
- Monitor your usage and rate limit headers to avoid unexpected throttling.
- Scale your plan based on actual metrics, not guesses.
Frequently Asked Questions
Can I test Solana apps for free?
Yes, most providers offer a free tier that includes access to devnet. OnFinality provides a public Solana devnet endpoint that you can use for testing without a paid plan. Check the Solana devnet page for details.
What's the difference between devnet and mainnet for testing?
Devnet is a public test cluster where you can get free SOL from a faucet. It's ideal for functional testing. Mainnet uses real SOL and reflects production conditions. Use devnet for most tests, but switch to mainnet for integration tests that need real-world state.
Do I need a dedicated node for testing?
Not usually. A shared plan is sufficient for most testing. You might need a dedicated node for load testing or if you require consistent performance without interference from other users. OnFinality offers dedicated nodes that you can spin up when needed.
How do I know if a plan's rate limits are enough?
Estimate your peak request rate during testing. If you're making hundreds of requests per second, you'll need a higher-tier plan. Most providers publish their RPS limits, and you can test with a script to see if you get 429 errors.
Are WebSocket connections counted separately?
Some providers count WebSocket connections against your plan's connection limit, while others have a separate allowance. Check the provider's documentation to understand how WebSocket usage is billed.
Can I switch plans easily if my testing needs change?
Most providers allow you to upgrade or downgrade your plan at any time. OnFinality lets you manage your subscription from the dashboard, so you can adjust as your testing evolves. Review the RPC pricing page for current plan options.
For a broader look at how Solana RPC providers compare, see our Solana RPC providers comparison. And if you're evaluating providers for production later, our guide to choosing an RPC provider covers additional criteria like uptime and support.
Related resources
Originally published at OnFinality.
Top comments (0)