Billing

Fauna billing is primarily based on the resources that you use in your queries. Fauna provides a generous free tier so that you can learn how the service works. You can also choose to purchase higher tiers that include predictable pricing or support. See the pricing page for more information.

The billing topic describes how resource usage is counted.

Terminology

Document

A JSON object stored in a Fauna database, which includes user-provided documents and Fauna schema documents, such as those describing databases, collections, indexes, keys, user-defined functions, and roles.

Query

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

Transactional Read Operation (TRO)

Fauna read operations. Fauna ensures strong consistency of all read transactions through strictly serializability based on their position in a global transaction log, because the order reflects the real-time processing order. Read-only transactions are serializable with an added consistent-prefix Read Your Own Writes (RYOW) guarantee. See the Fauna ACID compliance documentation.

Transactional Write Operation (TWO)

Fauna write operations. Like TROs, Fauna provides strict serializability for write operations, which is recognized as the ideal consistency model.

Transactional Compute Operation (TCO)

Fauna compute operations. In addition to storage-related operations, compute operations are required to manipulate data and include user-defined functions.

Metering details summary

Usage is billed based on the resources consumed by your API queries. A query results in a read, write, compute, storage, and other operations, depending on the shape of your query.

See Query log for information about how to get visibility into the billable events related to your API queries.

Usage type

Billing units

Metering details

Read requests

API calls to read data from your database are billed in TROs.

A read request, by default strongly consistent and transactional, of up to 4KB requires one TRO. For items larger than 4KB, more TROs are required. For example, a read request of an 8KB item requires two TROs.

Write requests

API calls to write data to your database are billed in TWOs.

A write request, by default transactional and replicated, of up to 1KB requires one TWO. For items larger than 1KB, more TWOs are required. For example, a write request of a 3KB item requires three TWOs.

User-defined functions (UDFs) and API calls

API calls to your database incur CPU usage that is billed in TCOs.

An API call with up to 50 function calls requires one TCO. For example, a Paginate(Match("users_by_email", "abc@fauna") call costs one TRO plus one TCO.

Data storage

Data written to your database is billed in terms of disk space used and is called Data Storage.

Storage is measured in GB and includes the total volume of data stored on disk for each write, including storage incurred for temporality. The amount of space occupied is charged monthly.

Event streaming

Streaming is billed as a sum of the time a stream is kept open, TCOs, and the number of events sent through the stream, TROs.

Each streamed event counts as two TROs, which include an initial 4k bytes read from storage plus one TRO per added 4k bytes read from storage per subscriber. One TCO is counted for every one minute that a stream is held open, per subscriber.

Backup snapshot creation

Compute units, TCOs, needed to create backup snapshots.

For example, if you back up a 1 GB database, the cost is 1000 MB * 100 TCOs, which is 100,000 TCOs for the snapshot plus the base charge of 20,000 TCOs, for a total of 120,000 TCOs.

Backup snapshot storage

Snapshot storage is billed based on size, in GB, and retention period, in days, and is called Backup Storage.

For every 1 MB of data stored per day, you are billed $.00005 in the US Region Group. For example, if you have 1 GB of backup snapshots stored for 30 days, that is 1000 MB * 30 * $.00005, which is $1.5.

Backup snapshot restore/copy

Compute units, TCOs, needed to restore or copy from a snapshot.

For every 1 MB of data restored or copied, you incur 100 TCOs on your bill. For example, restoring or copying a 1 GB database is 1000 MB * 100, which is 100,000 TCOs. The cost of TCOs you incur depends on the Region Group of your database. The US Region Group costs $2.05/million TCOs. So, for 100,00 TCOs, you are charged $.205 per restore or copy.

Query log

Log requests incur CPU usage, which is billed in TCOs.

Each log request is translated to TCOs based on the number of log lines received. Logs are billed in two tiers:

  • Requests that yield less than or equal to 100k lines cost 49,500 TCOs per request.

  • Requests that yield more than 100k lines cost 0.495 TCOs per line.

Metering unit rates summary

The following usage unit rates apply for the different geographic regions. See Region Groups for more information about Region Groups.

Billing units

US Region Group

EU Region Group

Transactional Read Ops (TROs)

$0.46/million

$0.55/million

Transactional Write Ops (TWOs)

$2.28/million

$2.73/million

Transactional Compute Ops (TCOs)

$2.05/million

$2.46/million

Data Storage

$1.00/GB/month

$1.20/GB/month

Data Transfer

Included

Included

Backup storage

$0.05/GB/day

$0.05/GB/day

Query log (TCOs)

$2.05/million

$2.25/million

Usage billing details

The following resources and operations are counted for billing purposes.

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

Read requests

  • One TRO is counted when up to 4 KB of a document is read from storage. A 20 KB document requires five TROs, a 4.1 KB document requires two TROs.

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

  • One TRO is counted when up to 4 KB of tuples is fetched from an index.

    Also, one TRO per index partition is counted. An index with no terms defined has eight partitions, so seven more TROs are counted beyond 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.

  • One TRO is counted when up to 4 KB of document history is read from storage. A 0.5 KB document with more than 32 KB of historical versions requires eight TROs.

  • TROs for authentication or identity checks are counted according to the size of the token or key. One TRO is counted when up to 4 KB is read.

  • TROs are 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 TROs again.

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

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

Write requests

  • One TWO is counted when up to 1 KB of a document is written to storage. A 20 KB document requires 20 TWOs, a 1.1 KB document requires two TWOs.

  • Index writes, for documents that are created, updated, or deleted, incur TWOs: one TWO is counted when up to 1k of index data is written, even when those writes span multiple indexes.

    Writing an index entry involves modifying four locations in index storage and includes the field values in the terms and values definitions plus the Reference and Timestamp from the covered document.

    You can reduce TWOs during index creation by creating the documents to be indexed first and the index afterward. 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 TCOs (read and write operations are not counted). You cannot query the index until the backfill is complete.

  • Generally, TWOs are not counted for queries that fail. The exception is contended transactions that fail with a 409 status code, for which TWOs are counted.

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

Compute

TCOs include user-defined functions (UDFs) and API calls.

  • One TCO is counted for up to fifty function calls.

  • During index writes, TCOs are incurred as if a Lambda function called Select once each for the terms and values definitions.

    When terms or values are not defined, the associated Select call does not occur, reducing the function call count.

    When neither terms nor values are defined, the Lambda is not called, so no compute ops are incurred.

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

  • The import command in fauna-shell performs TCOs.

See the x-compute-ops response 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. 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 about 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.

Be aware that Fauna stores all revisions to a document separately. Each document update contributes to the storage total. Deleting unused documents and their revisions reduces required storage. Setting the document ttl field, or the collection history_days or ttl_days fields, can indirectly reduce storage.

See Temporality for more information about temporality.

Streaming

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

    For example, when a stream event involves a single 20K document, six TROs are counted.

  • One TCO is counted for every one minute 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.

Snapshots

Snapshots for backups incur charges in three ways:

  • Snapshot creation: the number of TCOs required to produce a snapshot. One hundred TCOs are charged per megabyte of data captured in the snapshot, with a base of 20,000 compute operations.

    For example, for a 1-gigabyte database, the total TCOs required are 100 TCOs/megabyte × 1,000 MB
    20,000 TCOs = 120,000 TCOs.

    Pricing for TCOs varies by Region Group. If the cost for TCOs is $2.05/million, you are charged $0.24 USD for a 1-gigabyte snapshot in the US Region Group.

  • Snapshot retention: the number of gigabytes required to store cumulative snapshots.

    For example, the storage occupied for 30 days of 10 MB snapshots is 0.3 GiB, 30 days × 0.01 GiB.

    Pricing for storage varies by Region Group. If the cost of storage is $0.05 USD per gigabyte per day, you are charged $0.02 USD to store 30 days of snapshots at 10 MB each in the EU Region Group.

    Snapshots exist at the account level and are retained even if the original database is deleted or backups for a database are turned off. This is convenient when you need to recover a database that you deleted accidentally.

  • Snapshot restore/copy: the number of TCOs required to restore or copy a snapshot. One hundred TCOs are charged per megabyte of data restored/copied from a snapshot.

    For example, for a 1-gigabyte snapshot, the total TCOs to restore/copy the snapshot are 100 TCOs × 1,000 MB = 100,000 TCOs.

    Pricing for TCOs varies by Region Group.

See the pricing page for current snapshot rates.

Dashboard usage

Using the Fauna Dashboard to navigate your databases, collections, indexes, functions, keys, and tokens, plus running FQL or GraphQL queries, consumes read, write, and TCOs. The Dashboard uses the same queries that you might use to fetch the information.

The Dashboard tries to display the latest information available, so every time you navigate to a new display or refresh your browser, more queries are executed to populate the display.

Browsing your databases using the Dashboard incurs only a small fee. For you to incur $0.01 USD on your bill, you would need to consume more than 20,000 TROs or more than 4,000 TWOs. If your monthly usage is lower than your plan limits, Dashboard use does not incur extra cost.

Here are some guidelines for Dashboard usage:

Activity Expected read ops

Every time you visit the Home page

48

Every time you visit a database Overview page

32
+ <# of collections>
+ <# of indexes>

Every time you visit the Collection details page

8
+ <# of documents>

Every time you click the Collections button (in the left navigation pane)

8
+ <# of Collections>
plus the cost of loading the first Collection’s details.

Functions, indexes, keys, access providers, and roles are represented by documents, so browsing the other pages also incurs costs.

Varies

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 with 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 TRO for each of 26 letters, and eight TROs for the index that has no terms defined. This value contributes to the TROs billing.

  • x-byte-write-ops is 0, as no writes were performed during the query. This value contributes to the TWOs 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 are function calls divided by 50, rounded up. This value contributes to the TCOs 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 calculate the resource cost of running your queries, especially if your applications 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 to see the tooltip.

Billable operations in the Web Shell
The Fauna GraphQL API does not currently implement per-query billing headers.

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 databases that exist in your account. No data is lost or removed.

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

  3. If your access to databases is temporarily revoked, you can upgrade to a paid plan to have your keys/tokens reinstated. Reinstatement is a manual process, so your databases continue to look unavailable 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 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.

For paid plans, exceeding the plan limits does not cause your account to be paused. Usage of the database beyond the limits is billed at the on-demand metering rate.

Plan downgrades

Should you need to downgrade your current to a lower plan or to the Free plan, you must contact support@fauna.com.

  • There are no self-service downgrades.

  • The downgrade to the new plan occurs on the first business day of the following month. Your current plan remains in effect until then.

  • There is no "stop all charges now" option.

  • During the downgrade, a final invoice for the current plan is generated that covers the usage in the current month, including on-demand metering incurred since the downgrade request.

  • Once the downgrade is complete, the new plan takes effect.

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!