Query calls on the Internet Computer Protocol (ICP) are now much easier to understand, thanks to a fresh push towards clarity and measurement. These fast, lightweight calls—executed on just one node and designed to return synchronous responses—are an integral part of how developers interact with canisters, the smart contracts of the ICP.
Unlike update calls, which are replicated across nodes and run through consensus, query calls don’t alter the canister’s state. That also means they skip consensus entirely, making them far quicker—typically taking between 200 and 400 milliseconds. They’re ideal for fetching information in real time, without altering data or waiting for network-wide validation.
What makes this all the more appealing is that query calls are currently free. That’s a rare thing in blockchain systems, where every byte and cycle often comes with a price tag. Because they’re run on a single node, they’re not considered secure for critical transactions. Still, for everyday usage where speed and ease matter more than bulletproof trust, they’re perfectly suited.
Canisters, once deployed, become accessible through public endpoints. These can accept messages from users and other canisters. Among these, query calls are now more transparent than ever, thanks to the introduction of a query stats feature that gives developers insight into how their canisters are being accessed and used.
This feature is part of the canister status toolset and has been made available via a recent version of the development framework. It introduces useful counters that show the total number of query calls made, the amount of computing instructions used during those calls, and the payload sizes—both for incoming requests and outgoing responses. All values reflect activity since the canister’s creation and increase with use, allowing developers to track changes by checking periodically.
There are a few caveats. The stats are approximations, meaning they may not reflect every call, especially on lesser-used canisters. They’re also gathered in periodic snapshots rather than instantly, with a lag of up to 30 minutes. Despite this, they provide a much-needed layer of visibility in an environment where performance and efficiency often determine how useful a decentralised app actually is.
Developers can retrieve query stats with a single command and instantly get a breakdown of activity. It’s a minimal touchpoint with maximum benefit, offering not just reassurance that a canister is doing its job but also giving metrics that can be tracked, analysed, and used to guide improvements.
There’s also an extended mode of execution where a query can be run as if it were an update. This method does not change the final result—state changes are still discarded—but the call runs across all nodes and goes through consensus. It’s known as replicated query mode and adds a bit of trust back into the equation, albeit with the performance trade-off that comes with replication.
Beyond that, there’s been work on making query calls more flexible, especially for larger or more modular apps. Regular queries have a limitation: they can’t call other queries or composite logic. That can make things tricky when data is spread across multiple canisters.
To address this, composite queries have been introduced. These allow one query to call other queries—both regular and composite ones—enabling more complex logic to be executed in a single flow. This helps when building apps that scale horizontally, such as those partitioning data across a network of canisters for efficiency or redundancy.
Composite queries carry their own rules. They cannot be called as updates, and they cannot reach across subnet boundaries. Still, within those bounds, they offer developers a much more useful toolkit for building the kind of dynamic, responsive apps that users expect. On the flip side, update calls remain the only option for logic that needs to persist or where strict trust guarantees are required.
There are three main types of calls to consider: regular queries, updates, and composite queries. Regular queries are fast and isolated. Updates are secure and consensus-driven. Composite queries sit somewhere in between, offering some complexity and flexibility, though with trade-offs in terms of reach and usage.
The ability to make these calls easily—whether on a local setup, a test environment like the playground, or on the live ICP mainnet—is another feature that smooths the developer experience. All options are accessible using the same basic command, tweaked slightly depending on the environment being targeted. That consistency removes unnecessary barriers and means developers can build, test, and deploy without needing to switch mental gears or tools.
A key point is that query calls are free across all environments for now. That lowers the barrier for experimentation and usage, encouraging developers to adopt these faster methods where applicable. The main catch is security: because the response comes from a single node, there’s no guarantee it hasn’t been tampered with. For sensitive operations, certified queries or updates should be used instead.
For those monitoring performance, especially in production, the stats exposed by the system are a welcome change. They include the total count of query calls, the computational load measured in instruction units, and the size of both the request and response payloads. Each canister’s cumulative totals offer a picture of use over time, which is vital for managing capacity and understanding load patterns.
With composite queries now available and query stats making usage more transparent, developers working on ICP have more visibility and flexibility than before. These updates reflect a broader trend in the space—focusing on performance, usability, and clarity.
That’s especially important for anyone building apps that expect to scale. When data is distributed across multiple canisters or when users expect instant responses, knowing how queries perform and being able to optimise them can make or break the experience. The ability to calculate rates—by checking how stats change over intervals—adds another layer of insight.
On top of all this, there’s also support for calling canister status and reading query stats programmatically. This is helpful for automated monitoring or building tools that visualise performance data in real time. Even though composite query stats aren’t yet supported, the foundation is in place.
Altogether, the shift towards transparent, flexible, and efficient query management on ICP should encourage further development and adoption. It reflects an understanding that decentralised apps need not just robust infrastructure but also tools that help developers stay informed and responsive.
Whether used in testing environments or live deployments, these updates improve the development journey and set clearer expectations. Query calls may be simple, but they’re increasingly smart—and with the right stats in hand, developers can now treat them as more than just silent background processes.
They’re measurable, optimisable, and ready for action.
Community Discussion