---
title: Requirements
description: Hardware, database and network requirements, measured on the real data.
---

Measured on the data of 10 November 2026: 2.29 million RPO records, 1.02 million active subjects, the six
Financial Administration lists.

| Resource | Minimum | Comfortable |
| --- | --- | --- |
| PostgreSQL | 16, 17 or 18, with the `pg_trgm` extension | 18 |
| Database disk | 5 GB (about 2.3 GB of data, about 0.75 GB WAL during loads, headroom) | 10 GB |
| Database RAM | 1 GB | 2–4 GB |
| Database CPU | 1/8 vCPU: about 85 default searches a second at the limit; plan for up to about 30 | 1/4 vCPU or more: about 100–110 a second at the limit; plan for up to about 50 |
| Register container | 256 MB RAM; the sync peaks at about 30 MB | 512 MB |
| Work volume for `sync` | 1 GB during the first run; files are deleted once applied | — |
| Outbound HTTPS | The RPO bucket (Oracle Cloud, Frankfurt) and `report.financnasprava.sk` | — |

> **Warning**
>
> **Below the minimum is for trying only.** A smaller database, such as 1/16 vCPU and 512 MB, starts and answers, but
> its CPU and memory were at 100 % already at 10 searches a second, with no room for a burst or the monthly reconcile.
> For production, use at least **1/8 vCPU and 1 GB** (for example [PlanetScale PS-10](/self-hosting/planetscale#sizes)).

**How the CPU figures were measured**

On PlanetScale Postgres with the real data, the API about 20 ms from the database and a connection pool of 20. The
limit is where answers stopped keeping up; plan for about half of it. With a small pool the pool, not the CPU, sets
the limit. Details and the method: [PlanetScale Postgres](/self-hosting/planetscale).

**Any PostgreSQL works:** plain PostgreSQL, Neon, PlanetScale Postgres, Supabase, RDS. Only `pg_trgm` is needed; no
provider-specific extension.

## Where to run it

**[Docker compose](/self-hosting/docker-compose)**

The whole stack on one machine: PostgreSQL, migrations, the API and the sync.

**[Coolify and Dokploy](/self-hosting/paas)**

A compose variant for self-hosted PaaS platforms on your own server.

**[AWS](/self-hosting/aws)**

ECS Fargate with RDS for PostgreSQL, and the pitfalls specific to AWS.

**[Other platforms](/self-hosting/platforms)**

Any platform with a long-lived container and a scheduled job.

## The database

The register needs one PostgreSQL database, on your server or from a provider.

**[Any PostgreSQL](/self-hosting/database)**

Plain PostgreSQL, Neon, Supabase or RDS: roles, connections, the API pool and the objections backup.

**[PlanetScale Postgres](/self-hosting/planetscale)**

Tested with the real data: setup, measured sizes and online resizing.

## How long the first run takes

| Step | Measured |
| --- | --- |
| Download the RPO snapshot (about 940 MB, 6 parallel streams) | about 9 min |
| Apply the snapshot (2.29 million records) | 90 s |
| Daily files after the snapshot | under 1 s |
| Build the search layer and publish | 32 s |
| The six Financial Administration lists | 60 s |
| **Until `/readyz` answers `ready`** | **about 12–13 min** |

Most of the time is the download. On a very small database tier, expect 20–30 minutes (an estimate). An interrupted
first run resumes: applied parts are not downloaded again, and a partial download continues.

After that, an hourly pass with nothing new takes one to two seconds; a new daily file is applied in under a
second.