designed for SSDs and will perform poorly on HDDs; however it can handle far
more data than the alternative "memory" engine and is a better default
choice for most deployments. (Note that you can change the storage backend
on-the-fly for a given FoundationDB cluster using
{command}`fdbcli`.)

Furthermore, only 1 server process and 1 backup agent are started in the
default configuration. See below for more on scaling to increase this.

FoundationDB stores all data for all server processes under
{file}`/var/lib/foundationdb`. You can override this using
{option}`services.foundationdb.dataDir`, e.g.
```nix
{
  services.foundationdb.dataDir = "/data/fdb";
}
```

Similarly, logs are stored under {file}`/var/log/foundationdb`
by default, and there is a corresponding
{option}`services.foundationdb.logDir` as well.

## Scaling processes and backup agents {#module-services-foundationdb-scaling}

Scaling the number of server processes is quite easy; simply specify
{option}`services.foundationdb.serverProcesses` to be the number of
FoundationDB worker processes that should be started on the machine.

FoundationDB worker processes typically require 4GB of RAM per-process at
minimum for good performance, so this option is set to 1 by default since
the maximum amount of RAM is unknown. You're advised to abide by this
restriction, so pick a number of processes so that each has 4GB or more.

A similar option exists in order to scale backup agent processes,
{option}`services.foundationdb.backupProcesses`. Backup agents are
not as performance/RAM sensitive, so feel free to experiment with the number
of available backup processes.

## Clustering {#module-services-foundationdb-clustering}

FoundationDB on NixOS works similarly to other Linux systems, so this
section will be brief. Please refer to the full FoundationDB documentation
for more on clustering.

FoundationDB organizes clusters using a set of
*coordinators*, which are just specially-designated
worker processes. By default, every installation of FoundationDB on NixOS
will start as its own individual cluster, with a single coordinator: the
first worker process on {command}`localhost`.

Coordinators are specified globally using the
{command}`/etc/foundationdb/fdb.cluster` file, which all servers and
client applications will use to find and join coordinators. Note that this
file *can not* be managed by NixOS so easily:
FoundationDB is designed so that it will rewrite the file at runtime for all
clients and nodes when cluster coordinators change, with clients
transparently handling this without intervention. It is fundamentally a
mutable file, and you should not try to manage it in any way in NixOS.

When dealing with a cluster, there are two main things you want to do:

  - Add a node to the cluster for storage/compute.
  - Promote an ordinary worker to a coordinator.

A node must already be a member of the cluster in order to properly be
promoted to a coordinator, so you must always add it first if you wish to
promote it.

To add a machine to a FoundationDB cluster:

  - Choose one of the servers to start as the initial coordinator.
  - Copy the {command}`/etc/foundationdb/fdb.cluster` file from this
    server to all the other servers. Restart FoundationDB on all of these
    other servers, so they join the cluster.
  - All of these servers are now connected and working together in the
    cluster, under the chosen coordinator.

At this point, you can add as many nodes as you want by just repeating the
above steps. By default there will still be a single coordinator: you can
use {command}`fdbcli` to change this and add new coordinators.

As a convenience, FoundationDB can automatically assign coordinators based
on the redundancy mode you wish to achieve for the cluster. Once all the
nodes have been joined, simply set the replication policy, and then issue
the {command}`coordinators auto` command

For example, assuming we have 3 nodes available, we can enable double
redundancy mode, then auto-select coordinators. For double redundancy, 3