Alle Beiträge
5 Min. Lesezeit
When NOT to use Suward
The honest version. Workloads we don't fit well, where you should self-host, and how to tell the difference before you commit.
The honest version. Workloads we don't fit well, where you should self-host, and how to tell the difference before you commit.
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.
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.
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:
debug_setHead or miner_* (mostly mining-related, rarely useful)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.
eth_getLogs over huge rangeseth_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.
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:
eth_call simulations with state overrides that pin to a specific node's working stateWe 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.
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:
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.
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.
Three questions:
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.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.If you answer those three honestly, you'll know whether we're a fit.
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.