# Sizes, idling and lifetime

> Machine sizes and regions, stopping when idle, temporary databases, and how your data is kept safe.

Source: https://duckhouse.co/docs/databases

Each DuckHouse database is its own machine, with its own disk, running one DuckDB process. Nothing is shared with other customers, or with your other databases.

## Sizes

DuckDB uses every core and as much memory as it is given, so size mainly decides how large a query can get before it spills to disk. Start small; you can resize from the database's page, which restarts it.

| Size | CPU | Memory |
| --- | --- | --- |
| `shared-cpu-1x` | 1 shared vCPU | 512 MB |
| `shared-cpu-2x` | 2 shared vCPUs | 1 GB |
| `shared-cpu-4x` | 4 shared vCPUs | 2 GB |
| `shared-cpu-8x` | 8 shared vCPUs | 4 GB |
| `performance-1x` | 1 dedicated vCPU | 2 GB |
| `performance-2x` | 2 dedicated vCPUs | 4 GB |
| `performance-4x` | 4 dedicated vCPUs | 8 GB |
| `performance-8x` | 8 dedicated vCPUs | 16 GB |

Shared CPUs suit exploration and scheduled work. Choose dedicated CPUs when query times need to be consistent. Prices are on the [pricing page](https://duckhouse.co/pricing).

## Regions

Pick the region closest to whatever queries the database most: you, your application, or the sources you sync from. Available today: US East (Virginia), US West (Los Angeles), Europe (Frankfurt) and Asia (Singapore). A database stays in the region it was created in.

## Stop when idle

With this on, the machine stops when nothing is connected and starts again on the next connection. Compute is only billed while it runs; storage is billed either way.

-   Waking takes about five seconds, which the first query after a quiet period will notice.
-   Your data is untouched by stopping and starting. It lives on the machine's disk, not in memory.
-   It suits databases you query now and then. Leave it off for a database that backs a dashboard or an application, where a five-second first query would be felt.

You can also stop a database by hand from its page. That is a different kind of stop: a database you stopped stays stopped, and a connection will not wake it, until you press Start. Use it when you want to be sure nothing (a forgotten script, a BI tool polling in the background) can run up compute while you are away.

## Temporary databases

Give a database a lifetime of 1, 7 or 30 days when you create it, and it deletes itself afterwards, data included. This is meant for one-off analysis: load, explore, export what you need, and let it go. Through the [API](https://duckhouse.co/docs/api.md) you can set any lifetime in hours with `ttlHours`.

> Expiry is permanent. There is no grace period, and a deleted database cannot be restored.

## How your data is kept safe

-   **Primary copy:** an encrypted disk attached to the database's machine. DuckDB writes are transactional.
-   **Snapshots:** every five minutes, and again whenever the database stops, a consistent copy is written to object storage in a bucket that belongs to that database alone.
-   **Recovery:** if a machine's disk is ever lost, the database restores itself from its latest snapshot the next time it starts. In that case, writes made since the last snapshot, at most about five minutes' worth, would be lost.
-   **In transit:** every connection is encrypted with TLS.

Snapshots protect against hardware failure. They are not a history you can browse: there is no point-in-time restore yet, so keep your own export of anything you cannot recreate.

## Deleting a database

Deleting removes the machine, its disk, its snapshots and its bucket, and stops any [Connections](https://duckhouse.co/docs/connections.md) that fed it. It cannot be undone.