Prerequisites
Horizon only has one true dependency: a PostgreSQL server that it uses to store data that has been processed and ingested from Stellar Core. Horizon requires PostgreSQL version >= 9.5.
As far as system requirements go, there are a few main things to keep in mind. Starting from version 2.0, Horizon must be run as a standalone service. A full Horizon build consists of three functions:
- ingesting data from the decentralized Stellar network,
- submitting transactions to the network, and
- serving API requests
The first two happen through Captive Core, a pared down, non-validating version of Stellar Core packaged directly into Horizon.
With these three functions in mind, you can also run Horizon in two different ways: real-time ingestion and historical catch-up:
Real-time ingestion is an “online” process: it involves keeping in sync with the live Stellar network state and digesting ledger data into a holistic view of the network. If you just want function (3) from above, you still need to do this.
Historical catch-up is an “offline” process: it lets you look into the past and catch up your Horizon instance to a given retention period (e.g. 30 days of history). Because it’s typically done offline and a one-time process, you can dedicate more compute power and configure parallel workers to catch up faster.
Historical Catch-up
In this scenario, the hardware specifications are more demanding than what is necessary for the day-to-day operation of real-time ingestion, but catch-up only needs to occur once.
However, the requirements will vary depending on your chosen retention period and desired catch-up speed. Note that most operators will not need full history, and as the network continues to grow, tracking full history will become increasingly prohibitive. As of late 2021, DB storage to support historical retention is growing at a rate of 0.8 TB / month. It is highly recommended to configure retention of only the history needed to support your functionality.
Requirements
Minimally, your disk storage type must be an SSD (e.g. NVMe, Direct Attached Storage) and your I/O must handle >15k iops (I/O operations per second). The following table breaks down hardware specifications for ingestion at different retention levels and performance tiers.
Note that each component can be scaled independently and for redundancy, in the manner of traditional n-tier systems which is covered later in Scaling. Ingestion can be sped up via configuring more Captive Core parallel workers (requiring more compute and RAM).
Component | Retention Period | ||
---|---|---|---|
30 days | 90 days | Full History | |
Parallel worker count (est. ingestion time) | 6 workers (1 day) | 10 workers (1 day) | 20+ workers (2 days) |
Horizon | CPU: 10 cores (min: 6) RAM: 64 GB (min: 32) | CPU: 16 (min: 8) RAM: 128 GB (64) | CPU: 16 (10) RAM: 512 GB (256) |
Database | CPU: 16 cores (min: 8) RAM: 64 GB (min: 32GB) Storage: 2 TB IOPS: 20K (min: 15K) | CPU: 16 (12) RAM: 128 GB (64) Storage: 4 TB IOPS: 20K (15K) | CPU: 64 (32) RAM: 512 GB (256) Storage: 10 TB IOPS: 20k (15k) |
Storage (all same) | SSD (NVMe, Direct Attached Storage preferred) | ||
AWS (reference) | Captive Core: m5.2xlarge Database: r5.2xlarge | Captive Core: m5.4xlarge DB: r5.4xlarge | Captive Core: c5.2xlarge (x2)DB: r5.16xlarge (ro)r5.8xlarge (rw) |
Real-Time Ingestion
In this scenario, the goal is just to stay in sync with the Stellar network for day-to-day operations.
There are two extremes to this spectrum: running a single private instance of Horizon for a specific application all the way up to a serious enterprise public instance of Horizon. In the former case, you’d run all three functions on a single machine and have low request volume; in the latter case, you’d have high-availability, redundancy, high request volume, full history, etc.
Requirements
The following table breaks down requirements along this spectrum; if you fall somewhere in between, interpolate the requirements accordingly.
Category | Private Instance | Enterprise Public Instance |
---|---|---|
Compute | Both API Service + Captive Core: CPU: 4 RAM: 32 GB | API Service CPU: 4 RAM: 8 GB N instances, load balanced Captive Core CPU: 8 RAM: 256 GB 2 instances for redundancy |
Database | CPU: 4 RAM: 32 GB IOPS: 7k (min: 2.5k) | CPU: 32 - 64 RAM: 256 - 512 GB IOPS: 20k (min: 15k) 2 HA instances: 1RO, 1RW |
Storage (SSD) | depends on retention period | 10 TB |
AWS (reference) | API Service + Captive Corem5.2xlarge Database r5.2xlarge (ro)r5.xlarge (rw) | API Servicec5.xlarge (n) Captive Core c5.2xlarge (x2)Database r5.16xlarge (ro)r5.8xlarge (rw) |