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 page 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 up to 4KB of any document is read from storage. A 20KB document requires 5 read operations, a 4.1KB document requires 2 read operations.

    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 up to 4KB of tuples is fetched from an index.

    Additionally, one read operation per index partition is counted. An index with no terms defined has 8 partitions, so 7 additional read operations are counted above the number required to read a page from the 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 for authentication or identity checks are counted according to the size of the token or key; one read operation is counted when up to 4KB is read.

  • 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.

  • Read operations are not counted for the portions of a query involved in write operations. For example, if you Create a document, the result is incidentally read after the write completes, but does not accrue read operations.

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

Write operations

  • One write operation is counted when up to 1KB of any document is written to storage. A 20KB document requires 20 write operations, a 1.1KB document requires 2 write operations.

  • Index writes, for documents that are created, updated, or deleted, do incur write operations: one write operation is counted when up to 1k of document + index data is written. When a 1KB document is modified, and every field is indexed, two write operations are counted.

    You can reduce write operations during index creation by creating the documents to be indexed first, and the index afterwards. Indexes that were created after their source documents need to backfill their entries, which is a process that is handled by a background job (except when the number of documents is less than 128). For background job processing, Fauna only charges compute operations (read and write operations are not counted). However, you cannot query the index until the backfill is complete.

  • For queries that fail for any reason, write operations are not counted.

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

Compute operations

  • One compute operation is counted per fifty function calls, or portion thereof.

    User-defined functions might call many functions with each invocation; all function calls are counted. Compute operations might grow rapidly when using functions such as Map and Reduce, or when calling a UDF recursively.

  • The import command in fauna-shell performs compute operations.

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

Streaming operations

  • Each streamed event counts two read operations which includes an initial 4k bytes read from storage, plus one read operation per additional 4k bytes read from storage, per subscriber.

    For example, when a stream event involves a single 20K document, 6 read operations would be counted.

  • One compute operation is counted for every 1 second that a stream is held open, per subscriber.

See the x-byte-read-ops and x-compute-ops response headers 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. The size of indexes varies with the size of the data that is indexed.

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

There can be some inaccuracy in storage reporting due to server 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

Data transfer is included in the cost calculation for read, write, and compute operations. There is no separate billing for data transfer.

Snapshots

Snapshots for backups incur charges in three ways:

  1. Snapshot creation: the daily average gigabytes (GB) of snapshot creation per month multiplied by the creation rate.

    The daily average GB is the total GB of snapshot creation in a month divided by the number of days in a month.

    For example, when backups are enabled in April for a 1 gigabyte database, a 1 gigabyte snapshot would be created each day of the month, for a total of 30 GB. The daily average would be:

    30 GB ÷ 30 days = 1.0 GB / day.

    The creation charge would be 1.0 GB × the creation rate.

  2. Snapshot retention: the daily average gigabytes (GB) of snapshot retention per month multiplied by the retention rate.

    The daily average GB is the total GB of retained snapshots in a month divided by the number of days in a month.

    For example, if you have 1 gigabyte database backed up each day in March, and another gigabyte database backed up for only 5 days in March, the monthly retention total is:

    Days Retention / day Total

    5

    2 × 1 GB

    10 GB

    + 26

    1 × 1 GB

    26 GB

    31

    Total

    36 GB

    The monthly average storage is 36 GB ÷ 31 days = 1.16GB / day. The retention charge would be 1.16 GB × the storage rate.

    Note: Snapshots exist at the account level, and are retained even if the original database has been deleted, or if the database’s backups have been disabled. This is convenient in situations where you need to recover a database which you may have deleted erroneously.

  3. Snapshot restore/copy: the sum of the gigabytes (GB) restored or copied from snapshots per month multiplied by the restoration rate.

    For example, if you restore one 1 gigabyte snapshot, and make 2 copies of 1 GB snapshots, the total is 3 GB. The restore/copy charge would be 3 GB × the restore/copy rate.

See the pricing page for current snapshot rates.

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:

{
  'alt-svc': 'clear',
  'content-length': '4459',
  'content-type': 'application/json;charset=utf-8',
  date: 'Tue, 17 Nov 2020 22:57:46 GMT',
  via: '1.1 google',
  'x-byte-read-ops': '34',
  'x-byte-write-ops': '0',
  'x-compute-ops': '2',
  'x-faunadb-build': '20.11.00.rc8-01f9c94',
  'x-query-bytes-in': '120',
  'x-query-bytes-out': '4459',
  'x-query-time': '7',
  'x-read-ops': '27',
  'x-storage-bytes-read': '3047',
  'x-storage-bytes-write': '0',
  'x-txn-retries': '0',
  'x-txn-time': '1605653866258457',
  'x-write-ops': '0'
}

The query reads from a collection containing all 26 letters of the English alphabet, and it used the all_letters index to do so. The metrics associated with billing include:

  • x-byte-read-ops is 34, which is one read operation per letter (26 in total), and 8 read operations for the index (since an index with no terms specified has 8 partitions). This value contributes to the read operations billing.

  • x-byte-write-ops is 0, as no writes were performed during the query. This value contributes to the write operations billing.

  • x-compute-ops is 2. The Map, Paginate, and Index functions are called once each, Lambda and its Get and Var functions are called 26 times each, for a total of 81 function calls. The compute operations is function calls / 50, rounded up. This value contributes to the compute operations billing.

Note that the x-read-ops, x-query-bytes-in, x-query-bytes-out, x-write-ops, x-storage-bytes-read, and x-storage-bytes-write headers refer to legacy query accounting, and are not used in billing calculations.

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

The Web Shell provides this information as a tooltip for each query result (hover your pointer over the i in the white circle):

Billable operations in the Web Shell
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 Fauna Dashboard. Unfortunately, the reporting there is not real-time, lagging behind query usage by several hours (at least).

Exceeding limits

If you are using the Free plan and exceed the stated limits (as listed on the pricing page) in a calendar month, the following actions take place:

  1. An email notification is sent to the email address associated with your account, advising you of the situation.

  2. If you continue to use the service without upgrading to a paid plan, the keys/tokens that you use to access the service (from client applications) are temporarily revoked.

    The Dashboard no longer lists any databases that exist in your account. However, no data is lost or removed.

    The period between notification and revocation varies, but is approximately one week.

  3. If your access to databases has been temporarily revoked, you can upgrade to a paid plan to have your keys/tokens reinstated. Note that reinstatement is a manual process, so your databases continue to appear unavailable immediately after upgrade.

Reinstating access for temporarily-revoked keys/tokens requires contact with support@fauna.com, even if you have upgraded to a paid plan.

As mentioned, the Free plan’s limits are per calendar month. The metrics for account limits are reset on the first day of a calendar month. Accounts with revoked access have their access reinstated on the last day of a calendar month.

Was this article helpful? 

We're sorry to hear that.
Tell us how we can improve!
 Visit Fauna's forums or email docs@fauna.com

Thank you for your feedback!