Mysterious Shell Read and write ops

Hi, I’m new here. I opened an account 3 days ago, and my dashboard already shows 3 700 read ops using the shell. While the real number should be something like 7. Write ops should be a number like 2 and it shows 200. And while I don’t really know what compute ops measure precisely. I doubt that they should be so high.

Fauna seems like a great database to start a project fast with. Though I’d really love this problem to be solved. Not being able to trust my numbers is a deal-breaker for me : I don’t want to get billed for more than 100 times my usage.

I have seen a few posts on this forum dating of last April, mentioning the same problem, it was said that it had been patched though. Maybe something new went wrong.

Thanks a lot for the help :pray:

1 Like

Hi @timothee and welcome!

Going back to earlier this year, there was an issue that cause the dashboard to fetch data too often, but that was resolved. What you see is the dashboard working.

That’s a fair sentiment. However, the usage you see is from navigating the dashboard alone, and those operations will not scale with an application’s queries from other sources.

The image that you shared confirms that all of the operations are from the Dashboard, since we can see that the Total operations match the “Dashboard/Shell/Playground” operations. Here’s a zoomed-out image of my dashboard to highlight the row headers.


Calculation Read and Write Operations

Every call to create, read, update, and delete Fauna Indexes and Documents requires a cost in the form of Read, Write and Compute operations. Storage as well, but that is harder to measure on a query-by-query basis, and we’re focused on Read and Write operations here.

If you are new, you should be sure to understand the nature of Fauna’s schema. That is, Fauna’s Collections, Indexes, Functions, Roles, Databases, Keys, Tokens. etc. are all kinds of Documents. That means that reading, writing, creating, deleting schema also costs read and write operations.

If you have created a Database, a Collection, and added just one Document from within the Dashboard, then you’ve already cost yourself 3 Write Ops at least and at least 60 to 80 Read Ops. Let’s dig into why that is!

Check out the docs Billing page for additional information on how costs are calculated. At the end of the docs page, it shows you how you can inspect the response headers to view how many operations a query costs. I will do that to walk through the cost of some operations.

Dashboard operations

Navigating the dashboard costs read operations to fetch your information the same as it would if you queried for it yourself. Just about every action you take on the dashboard will require read operations.

So far we considered these actions:

  1. Sign up and log in
  2. Create a new database
  3. Create a Collection in our new database
  4. Create a Document in our Collection

So what has actually happened so far?

1. Sign up and log in

When you sign up and log in for the first time the dashboard requests the list of all Databases for your account. The Dashboard also brings together all of your data across the different Region Groups, so it actually has to do this 3 times (for Classic, US, and EU).

  • Query: Paginate(Databases(), { size: 1000 }).
    • 16 Read Ops * 3 = 48 Read Ops
    • 0 Write Ops

NOTE: Paginating the list of Schema, including Collections, Indexes etc. works on internal indexes with 8 partitions, so it costs at least 8 Read Ops to query them. Querying Databases requires 2 internal Index reads, so it costs 16 Read Ops. See the Billing docs for more information.

Here is me doing the same operation in the web shell. Note the result byteReadOps: 16 and byteWriteOps: 0


2. Create a Database

From the main page, you click the button to create your first database.


Once the database is created, it Dashboard will load the DB Overview screen, which includes a list of the database’s Collections, Indexes, and child Databases




3. Create a Collection

From the DB Overview screen, you should now see an invitation to “Create your first Collection”. So you click the “Create Collection” button. You are taken to the Create Collection screen, enter the information and click “Create”


Once the Collection is created, the dashboard loads the Collections screen and displays the details for the first Collection in the list. In this case, it’s just the one you created, but the dashboard doesn’t know that. In order to display this page correctly it needs to:

  • List all of the Collections in your database
  • For the first Collection found, Get and list the first 50 Documents


Listing all of the Collections now costs 9 Read ops. That’s 8 for the Paginating the Index, and 1 more for actually fetching the users Collection.


The Documents function works on a built-in index with no terms, so reading the list of Documents in the Collection also costs 8 Read Ops, for now, and will cost more once we add users. (see the Billing docs)

4. Create a Document

The Collection detail screen tells you that there are no documents yet, so let’s create one! Click the “New Document” button. Fill out the new-document form and click “Save”.


Once the Document is created, we are taken to the Show Document screen and the Dashboard requests the latest version of the Document.


Side note: this is a pretty round-about way, in my opinion, for the Dashboard to get a single document. You should probably just use Get(Ref(Collection("user"), "315427305906242129")). However, the cost is the same either way: 1 Read Op.

Having inspected your new Document, I’ll add one more step. Navigate back to the Collections screen.

Again we will list all of the Collections in the DB, and for the first Collection list the first 50 Documents.



The cost of viewing all of the Documents for the users Collection has increased to 9. This is because we first Paginated the Index (for 8 Read Ops) then used Get once to retrieve our single Document.

Tallying everything up so far

What was the cost of going through this in the dashboard so far?

  • Read Ops: 116
  • Write Ops: 3

It feels like we have done very little so far, but remember that the Dashboard has been presenting you with more information to provide the user experience it was designed for. Every time you navigate or refresh your browser, the dashboard requests updates from the database. It is tempting to suggest the information should be cached for better cost and performance, but the tradeoff would be to not receive the latest information, and that would be too disruptive to the user experience.

Rules of thumb for dashboard operations

  • Every time you visit the Home page, expect 48 Read Ops
  • Every time you visit a DB Overview page, expect 32 + [# of Collections] + [# of Indexes] Read Ops
  • Every time you visit the Collection details page, expect 8 + [# of Documents] Read Ops
  • Every time you click the Collections nav button, expect 8 + [# of Collections] Read Ops, plus the cost of loading the first Collection’s details.
  • Functions, Keys and Roles are also plain ol’ Documents underneath, so browsing the other pages will have required costs as well.

Monitor these operations in your browser

All of these requests are made directly from your browser to fauna. As you navigate around the dashboard, you can monitor the traffic in your network tab to see what requests are being made and how much they cost. This is how I determined the steps to take for this post.

You’ll see the FQL protocol in the request body.

And the cost in the response headers.

1 Like

Hi @timothee. Has this helped? Please let us know if you have any more questions.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.