With the release of Horizon 2.0, we’ve introduced a new way to run the infrastructure that powers the Stellar network. This paradigm shift enables large organizations and small developers alike to deploy Horizon with fewer resources, under looser constraints, and with far more flexibility than ever before.
In the past, you needed to run a Stellar Core node to deploy Horizon, which burdened you with heavy disk space requirements and careful configuration necessitated by Stellar Core. The old architecture's complexity didn't make sense for a lot of use-cases, and it wasn't negotiable: batteries were included whether you needed them or not.
Now, you can choose a setup that fits your use case. Instead of following a universal blueprint, you first answer an important question: What do you want to do? Do you want to run a validator? Or do you just want to run Horizon?
If you decide you want to run a validator, then you should check out the documentation on configuring and deploying a Stellar Core node, whereas if you decide you just need Horizon, then you can keep it simple and read about deploying an API server.
Here's what the old architecture looked like:
Some of the lowlights of this architecture should be apparent to anyone who deployed this architecture in the past:
All of these limitations have been resolved with the introduction of Horizon 2.0. Fortunately, that was then, and this is now:
The beauty of the new, modular architecture is that it presents simpler configurations that can adapt to all kinds of use-cases:
While deploying a full Stellar Core node can still be an involved process, the introduction of Captive Stellar Core lets you focus almost entirely on deploying Horizon itself, letting you participate in the network without bearing the full responsibility of consensus management.
Unlike selecting a starter Pokémon, changing your mind about your architecture is not difficult after the fact. If you suddenly find yourself vested in the decentralization of the network and want to run a validator, the standalone Stellar Core instance can be deployed independently while your Captive Core instance continues to work with Horizon. The inverse is also true: if you are running a validator and decide running Horizon is all you care about, all it takes is a bit of reconfiguration to introduce the Captive Core instance and enjoy the performance and architectural benefits it provides.
As already mentioned, the system requirements differ from previous architectural versions largely due to the changes in how Stellar Core interacts with Horizon. Specifically, the in-memory database requires around 3 GiB of RAM, and the disk space requirements have dropped significantly (again, by hundreds of gigabytes).
As always, a more-powerful machine results in faster ingestion, but it’s worth noting that after an initial ingestion, staying “online” is much less resource-intensive. Furthermore, it’s rare that an organization actually needs the full ledger history, and can thus get away with ingesting much smaller ranges of transaction metadata.
Horizon 2.0 introduces massive performance and architecture benefits that makes running Stellar infrastructure easier than ever:
Excited about these changes? Check out the migration guide to get started today!