When NOT to use Suward

Most "RPC provider vs. self-host" posts boil down to "use us, here's why." This one is the opposite. There are real workloads where Suward isn't the right fit, and we'd rather you know upfront than discover it three months in.

You should self-host if...

Your workload is mostly archive

By "archive" I mean: state at block N where N is more than ~12,800 blocks behind the chain tip (roughly two days on Ethereum mainnet). Archive queries — eth_call with a historical block, debug_traceTransaction on a year-old tx, eth_getStorageAt at a snapshot in the past — are expensive on the upstream side because the node has to traverse a much larger state trie or replay history.

Every CU-pricing provider, ours included, surcharges archive calls. The free tier covers a few thousand archive lookups; sustained archive workloads end up paying $200+/month for what a single archive node on a $40/month VPS could serve.

Signal: if more than 30% of your calls reference a block number more than 12,800 below the head, you should self-host an archive node or talk to us about flat-rate node access.

You need a custom tracer or custom RPC method

Every provider exposes a fixed method allowlist. We expose a generous one (the standard JSON-RPC set plus the popular tracers), but we don't expose everything. If you need:

• A custom Geth tracer compiled into the client
• An unofficial method like debug_setHead or miner_* (mostly mining-related, rarely useful)
• A patched node that exposes pre-execution state inspection
• The Reth-specific reth_* methods on a non-Reth provider

...you're going to hit a wall. Self-host the specific client you need.

Signal: check our method allowlist on the docs page for the chain you care about. If the method you need isn't there and isn't on the roadmap, self-host.

You're running a high-throughput indexer that needs eth_getLogs over huge ranges

eth_getLogs with fromBlock ≥10k blocks below toBlock is rate-limited everywhere — including us. We cap a single call at 10,000 blocks. If you need to backfill a Uniswap V3 indexer from block 12,000,000 to head, that's thousands of paginated calls, and the CU bill grows linearly.

For backfill workloads specifically, a self-hosted archive node + Ponder / Subsquid / Goldsky is cheaper. The total cost is a one-time engineering hit (a few days) and ~$300/month for the node — vs. ~$1,500–3,000/month of CU for the same workload through a provider.

Signal: if your indexer backfill spec includes the word "all" or "from genesis," you want self-hosted.

You need a pinned upstream

Suward routes your call to whichever upstream is healthiest right now. That's usually what you want. But occasionally you need the same upstream for the whole session — for example:

• WebSocket subscriptions that need a stable view of the mempool
• eth_call simulations with state overrides that pin to a specific node's working state
• MEV bot strategies that depend on a particular upstream's mempool ordering

We can support pinning at the enterprise tier, but if your whole workload is "give me one specific node, don't ever route me anywhere else," you should self-host or use a single-node provider.

Signal: if your code starts with // IMPORTANT: do not change this upstream between calls, you're not a great fit for a load-balanced provider.

You're on a chain we don't support

We're at 29 chains today. That's most of the EVM tier-1, all of the major L2s, plus Solana and Bitcoin. We're not on:

• Cosmos chains (Osmosis, Juno, Stargaze, etc.) — Tendermint RPC is shaped differently and we don't aggregate it yet.
• App-chains and OP-stack rollups that aren't on the public list (e.g. private chains, testnet variants).
• Newly-launched chains in their first 3–6 months. We wait for ecosystem maturity.

For these, you either self-host or use a chain-specific provider.

Signal: check the chain list on /chains. If your chain isn't there, we won't be a good fit until it is.

You should use Suward if...

The mirror-image of the above. You want a managed multi-chain endpoint, your workload is mostly read-heavy with occasional writes, you don't need bleeding-edge tracers, your data is fresh (≤2 days old), and you'd rather spend your time on product than on operating a node fleet.

That's most apps. Frontends, wallets, NFT marketplaces, DeFi dashboards, small-to-mid indexers, monitoring stacks. We're built for that profile.

How to tell the difference before you commit

Three questions:

1. What's the age distribution of the blocks you query? Run awk over a day of access logs against your dev environment. If the median is "head" and the 95th percentile is "head − 1000 blocks," you're a fit. If the 95th is "head − 1,000,000," you want archive.
2. Which methods dominate your CU bill? The 80/20 of most apps is eth_call + eth_getBalance + eth_blockNumber. Cheap. If yours is debug_traceCall + eth_getLogs(huge range) + trace_block, expect to pay an order of magnitude more.
3. How tolerant are you of an occasional 50–100ms latency bump during upstream failover? If "very" → managed is fine. If "not at all" → pin a single upstream and accept the operational cost.

If you answer those three honestly, you'll know whether we're a fit.

The other thing nobody says

Provider lock-in is real, and we're not magically immune to it. If you build against our endpoint shape (https://<chain>.suward.com/<YOUR_KEY>) and our auth header format, switching to a different provider is a search-and-replace plus a re-test. We've tried to keep the surface as close to vanilla JSON-RPC as we can, exactly so this stays easy.

We'd rather you stay because the product is good, not because the migration is painful.

Honest assessment? If you've read this far and you're still unsure, hit us on Telegram with your workload shape. We'll tell you straight whether we're the right fit — including pointing you elsewhere if we're not.