Check out v4 of the Fauna CLI

v4 of the Fauna CLI is now in beta.

The new version introduces enhancements to the developer experience, including an improved authentication workflow. To get started, check out the CLI v4 quick start.

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 with predictable pricing or support. See the pricing page for more information.

This section 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 queries through strictly serializability based on their position in a global transaction log because the order reflects the real-time processing order. Read-only queries are serializable with an added consistent-prefix Read Your Own Writes (RYOW) guarantee. See the Fauna ACID compliance documentation.

You can track TRO consumption using the read_ops property in query and event stats.

Transactional Write Operation (TWO)

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

You can track TWO consumption using the write_ops property in query stats.

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.

You can track TCO consumption using the compute_ops property in query and event stats.

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 Fauna Logs 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 4 KB requires one TRO. For items larger than 4 KB, more TROs are required. For example, a read request of an 8 KB item requires two TROs. Note also that the size is rounded up in the calculation. For example, reading 1.1 KB costs two TRO.

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 1 KB requires one TWO. For items larger than 1 KB, more TWOs are required. For example, a write request of a 3 KB item requires three TWOs. Note also that the size is rounded up in the calculation. For example, writing 1.1 KB costs two TWOs.

User-defined functions (UDFs) and API calls

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

An API call with up to 50 function calls requires 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.

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 per million TCOs. So, for 100,00 TCOs, you are charged $.205 per restore or copy.

Fauna 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 Global Region Group

Transactional Read Ops (TROs)

$0.46/million

$0.55/million

$0.69/million

Transactional Write Ops (TWOs)

$2.28/million

$2.73/million

$3.42/million

Transactional Compute Ops (TCOs)

$2.05/million

$2.46/million

$3.08/million

Data Storage

$1.00/GB/month

$1.20/GB/month

$1.50/GB/month

Data Transfer
(See Data Transfer, egress)

$0.20/GB/month

$0.20/GB/month

$0.20/GB/month

Backup storage

$0.05/GB/day

$0.05/GB/day

$0.05/GB/day

Fauna Log (TCOs)

$2.05/million

$2.46/million

$3.08/million

Rates for the Global Region Group are 1.5 times the US Region Group rates.

Data Transfer, egress

Free / Pay as you go Startup Pro / Free Trial Enterprise Virtual Private Fauna

2 GB included then $0.20/GB

10 GB included then $0.20/GB

50 GB included then $0.20/GB

100 GB included then $0.20/GB

100 GB included then $0.20/GB

Usage billing details

The following resources and operations are counted for billing purposes.

Read requests

FQL reports only byte read ops, which means that the number of bytes read in the query are aggregated and rolled up into the read_ops stats it reports.

The following functions incur TROs:

AccessProvider

AccessProvider.byName()
AccessProvider.firstWhere()

Collection

Collection.byName()
Collection.firstWhere()

Credential

Credential.byDocument()
Credential.firstWhere()
exists()
login()
verify()

Database

Database.byName()
Database.firstWhere()

Document

exists()

Function

Function.byName()
Function.firstWhere()

Key

Key.firstWhere()
exists()

Role

Role.byName()
Role.firstWhere()

Set

Set.paginate()
aggregate()
any()
count()
every()
first()
firstWhere()
fold()
foldRight()
forEach()
includes()
isEmpty()
last()
lastWhere()
nonEmpty()
paginate()
reduce()
reduceRight()
toArray()

Token

Token.byDocument()
Token.firstWhere()

Sets materialize when returned by a query, which is semantically equivalent to adding a .paginate() call to it. Therefore, queries returning Sets, as in the following example, incur read ops even though they didn’t call for any of the preceding Set functions.

Product.all().map(.name)

Similarly, documents are lazily materialized as needed so, although Product.byId(123) doesn’t read bytes instantly, projecting a field out of it requires a read and, therefore, incurs read ops. For example:

let doc = Product.byId("111")  // No reads so far
doc!.bar                       // Reads the doc

Some functions don’t incur read ops if their results aren’t used. For example:

let set = Product.all().reverse()  // No reads done for the Set
Product.byId("111")                // Reads done for the document

This query reports fewer read-ops than the following query:

let page = Product.all().reverse().paginate(10) // Reads done for the Set
Product.byId("111")                             // Reads done for th

Document write methods, such as document.update() or document.replace(), always perform a document read before writing to an existing document. This applies even if the query otherwise only reads from an index. Fauna doesn’t support blind writes to existing documents.

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

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.

One TRO is counted when up to 4 KB of document history or data is read from storage.

To support temporal queries, indexes cover field values from both current documents and their historical document snapshots.

To enable quicker sorting and range searches, current and historical index entries are stored together, sorted by index values. All indexes implicitly include an ascending document id as the index’s last value.

When you read data from an index, including the collection.all() index, Fauna must read from both current and historical index entries to determine if they apply to the query. Fauna then filters out any data not returned by the query.

You are charged for any Transactional Read Operations (TROs) used to read current or historical index data, including data not returned by the query.

You are not charged for any historical data older than the retention period set by the history_days setting.

Example

An index entry with 0.5 KB of current data and more than 32 KB of historical data requires eight TROs.

When reading documents directly, such as when using collection.byId(), Fauna only fetches the current version of the document. You are not charged for historical data.

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 because of conflicts with other concurrent queries that are writing to the same documents, the query is retried and incurs TROs again.

Write requests

FQL only reports byte write ops, which means all bytes written during the query are rolled up into its write_ops stats reported.

The following functions incur TWOs:

AccessProvider

AccessProvider.create()

Collection

Collection.create()

Credential

Credential.create()
delete()
login()
replace()
update()

Database

Database.create()

Document

delete()
replace()
update()

Function

Function.create()

Key

Key.create()
delete()
replace()
update()

Role

Role.create()

Token

Token.create()
delete()
replace()
update()

One TWO is counted when up to 1 KB of a document is written to storage. A 20 KB document requires 20 TWOs and 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 (ts) from the covered document.

Indexes created after their source documents must 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, associated read, write, and compute charges are included. You can’t query the index until the backfill is completed.

Adding constraints requires indexes in the background. Those indexes have a write cost associated with creating a terms index on the unique fields.

TWOs aren’t typically 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.

The fauna-shell import command incurs TWOs.

Compute

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

Every function call, operator call, and field projection incurs one fiftieth of a TCO. The Set.toArray() method, for example, costs one TCO for every 50 items in the Set:

let doc = Product.byId("111")  // 1 compute op
doc!.bar                       // 1 compute op
2 + 2                          // 1 compute op
doc!.bar + 2                   // 2 compute ops
Product.all().toArray          // N compute ops

During index writes, TCOs are incurred because an anonymous function is called to project each term and value covered.

User-defined functions might call many functions with each invocation. All function calls are counted. TCOs might grow rapidly when using functions such as set.map() and set.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.

Adding constraints requires indexes in the background. Those indexes have a storage cost associated with creating a terms index on the unique fields.

Storage reporting is a continuous process where the storage occupied by each database is determined daily. 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 because of server topology changes. When this occurs, the reported storage is less than the actual, resulting in lower billing.

Each revision to a document is stored as a separate version snapshot. 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 Document history and Document time-to-live (TTL).

Event Streams

For each streamed event:

  • Two TROs are consumed for the initial 4KB read from storage.

  • One additional TRO is consumed per 4KB read from storage, per subscriber.

For example, an event with a 20KB document and one subscriber consumes 6 TROs.

While a stream is open, one TCO is consumed per minute, per subscriber.

Events include a stats field you can use to track consumed TROs and TCOs. See event schema.

Backup and restore

Backup and restore billing includes charges to:

Charges for creating and restoring snapshots are in Transactional Compute Operations (TCOs). Pricing for TCOs varies by Region Group.

Create snapshots

Creating a database snapshot costs a baseline fee of 20,000 TCOs plus an additional 100 TCOs per MB of the database size.

Example

Creating a snapshot for a 100 GB (100,000 MB) database costs:

20,000 TCOs + (100,000 MB * 100 TCOs/MB) = 10,020,000 TCOs

In a Region Group with a rate of $2.05 USD per million TCOs, the monetary cost is:

10,020,000 TCOs * $2.05/million TCOs = $20.541

Store snapshots

Storing a database snapshot costs $0.05 USD per GB per day. You’re billed for each snapshot stored.

Example

Storing a snapshot for a 100 GB database costs:

100 GB * $0.05 = $5 per day

The cost to store a snapshot for the database for 30 days is:

30 days * $5 = $150

If daily backups are enabled, the cumulative cost to store 30 days of snapshots is:

30 snapshots * $150 = $4,500

Restore snapshots

Restoring a database snapshot costs 100 TCOs per MB of the database size.

Example

Restoring a snapshot of a 100 GB (100,000 MB) database costs:

100,000 MB * 100 TCOs/MB = 10,000,000 TCOs

In a Region Group with a rate of $2.05 USD per million TCOs, the monetary cost is:

10,000,000 TCOs * $2.05/million TCOs = $20.50

Integrations

The Datadog integration consumes TCOs based on the number of log entries sent to Datadog per month:

Number of log entries sent per month TCOs consumed per month

Fewer than 100,000

49,500 TCOs (flat rate)

100,000 or more

0.495 TCOs per log entry

Dashboard usage

Using the Fauna Dashboard to navigate your databases, collections, indexes, functions, keys, and tokens, plus running FQL queries, consumes read, write, and TCOs. The Dashboard uses the same queries 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. To incur $0.01 USD on your bill, you must 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 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 query metrics are reported in the JSON response stats field. You can use this information to accurately calculate the resource cost of running your queries, especially if your applications execute them frequently.

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!