Billing

Fauna billing is primarily based on the resources that you use in your queries. Fauna provides a generous free tier and you are only billed if you exceed the free tier’s limits. You can also choose to purchase higher tiers that provide predictable pricing, or support. See the pricing page for more information.

This pages describes how resource usage is counted.

Definitions

Document

A document is any record stored within a Fauna database, which includes user-provided documents and Fauna schema documents, such as those describing databases, collections, indexes, keys, user-defined functions, roles, etc.

Query

An expression of one or more FQL functions intended to achieve, or return, a specific result. Queries are executed as an all-or-nothing transaction by Fauna.

Resources

For billing purposes, use of the following resources is counted:

Read operations

  • One read operation is counted when any document is read from storage.

    When a query involves a distinct document multiple times, the document is only read once, not once per instance in the query.

  • One read operation is counted when a page of tuples is fetched from an index.

    When a query involves a distinct page from an index multiple times, the index page is only read once, not once per use in the query.

  • Read operations are always counted, whether the query fails or not.

  • If a query has to be retried due to conflicts with other concurrent queries that are writing to the same documents, the query is retried and incurs read operations again.

  • The following functions perform reads:

  • The following functions perform reads when they operate on Set references:

See the x-read-ops header in the Per query metrics section.

Write operations

See the x-write-ops header in the Per query metrics section.

Storage

  • Documents are stored on disk, and the amount of space occupied is charged monthly.

  • Indexes are also stored on disk, and contribute to the storage that is charged monthly.

Storage reporting is a continuous process, where the storage occupied in each database is determined approximately once per week. The billed amount for storage is determined by taking an average of the weekly storage reports in a calendar month.

There can be some inaccuracy in storage reporting due to replica topology changes. When this occurs, the reported storage is less than the actual, resulting in lower billing.

One non-obvious contributor to storage is that Fauna stores all revisions to a document separately: each update contributes to the storage total. Deleting unused documents directly reduces required storage. Setting a document’s ttl field, or a collection’s history_days or ttl_days fields, can indirectly reduce storage.

Removal is handled by a background task, so once a document (including collections, databases, indexes, keys, roles, and tokens) "expires" due to the setting in the ttl field, it could be some time (hours or days) before the removal occurs. There is no guarantee that removal actually occurs.

As of version 3.0.0, the ttl field is honored on read — a document that should have been removed behaves as if it has been removed. However, until removal actually occurs due to background task processing, you can continue to access the history of the document, provided you have its reference, via the Events function.

Data transfer

The amount of data transfer required to provide query responses is charged monthly.

If the client executing queries is co-located within the same cloud provider and region as a Fauna replica, data transfer is not billed for those queries.

See the x-query-bytes-out header in the Per query metrics section. Note that it does not tell you whether the data transfer was billed or not.

Per query metrics

Fauna FQL queries are performed over HTTP connections, and responses include headers that indicate the resources used in the current query.

For example, for the following FQL query performed with the JavaScript driver:

client.query(
  q.Map(
    q.Paginate(q.Match(q.Index('all_letters'))),
    q.Lambda("X", q.Get(q.Var("X")))
  )
)
.then((ret) => console.log(ret))

The following response headers were included with the query result:

{ connection: 'keep-alive',
  'content-encoding': 'gzip',
  'content-length': '400',
  'content-type': 'application/json;charset=utf-8',
  date: 'Tue, 03 Dec 2019 22:41:18 GMT',
  vary: 'Accept-Encoding',
  'x-faunadb-build': '2.10.0',
  'x-query-bytes-in': '120',
  'x-query-bytes-out': '4459',
  'x-query-time': '118',
  'x-read-ops': '27',
  'x-storage-bytes-read': '0',
  'x-storage-bytes-write': '0',
  'x-txn-retries': '0',
  'x-txn-time': '1575412878539354',
  'x-write-ops': '0' }

The query reads from a collection containing all 26 letters of the English alphabet, and it involved a read from the all_letters index, which is why x-read-ops is 27.

You can use this information to accurately determine the resource cost of running your queries, especially if your application(s) execute them frequently.

The Fauna GraphQL API does not currently provide per-query billing headers. You would have to correlate your API usage with the reporting available in the Dashboard. Unfortunately, the reporting there is not real-time, lagging behind query usage by several hours (at least).

Is this article helpful? 

Tell Fauna how the article can be improved:
 Visit Fauna's forums or email docs@fauna.com

Thank you for your feedback!