Get Started with Mercury

Learn about Mercury and whether it's a good fit for your use-case.

Thanks for taking an interest in Mercury, you have now landed on our documentation! Here you will learn about Mercury, its fundamentals, and API, and will begin retrieving on-chain data in minutes.

Let's start by understanding what Mercury is and whether it's a good fit for you.

What is Mercury?

Mercury is the most powerful managed indexing service running on the Stellar Network. It allows projects to retrieve on-chain data efficiently to display user information, plot beautiful and interesting charts, track the growth of an ecosystem, and much more. In short, whenever you are dealing with on-chain Stellar and Soroban data, there's a high probability that Mercury will come in handy.

Mercury's infrastructure runs a Stellar node, takes as input information about data you want to be able to access, and organizes it in our database in real time as new ledgers close. In parallel, you can use our efficient GraphQL API to retrieve that data for your services.

When should I use Mercury to retrieve my data?

Using an indexer is a common practice for decentralized applications, services, and wallets. However, in the Stellar ecosystem, we've never really had one. That's because the current ledger holds all the information about on-chain data, and due to Stellar entries always having been pre-defined data structures, services such as Horizon (or running self-hosted ingestion) have been (and still are!) enough for most use cases.

With the introduction of the Soroban Virtual Machine in Stellar validators, however, a whole new world of applications that rely on custom contract-defined data structures, unregistered (in the ledger) metadata, and more meticulous retrieval needs will emerge. These services either need to:

• Rely on block explorers. This is a valid option, but will generally be slower, with less specific querying options, and not customizable in any way.

• Rely on a self-hosted ingestion workflow, running and maintaining an instance of Stellar core, a database, and ingestion logic.

• Rely on managed indexing services.

Mercury belongs to the third category of data providers. We are a managed indexing service, so everything from ingestion to the external GraphQL API is controlled by us. This has both numerous advantages and disadvantages, and below we will try to give you an overview.

Pros
No-Setup. There's no need for any kind of setup. On Mercury, just subscribe to the data you need and start querying!
No Maintenance. There's no need for performing maintenance, keeping stellar nodes up to date, monitoring activity, and so on.
Cheaper. Using a managed indexing service is almost always cheaper than running your own ingestion. Additionally, our subscription design makes Mercury a very cost-efficient way to index your projects.
Security. While it's true that you don't have control over the security of the product you're relying on, our team does. We are committed to building a secure product, have a solid background in security research, and plan to have our code audited soon.
Smooth experience and support. Managed services offer a smoother experience due to the nature of their design, also including more specific support.

Cons	The Mercury Way
Vendor lock-in. When you're running a self-hosted indexer you don't have constraints around which server you use and you don't have to worry about lack of availability on the service's end. For example, if you want to migrate to another service, self-hosted services offer a much smoother experience.	While there is no way to counter vendor lock-in, we are committed to working with users who want to migrate to another service and plan to eventually implement DB channels to migrate data, even though it's not currently a priority. We also plan to host our infrastructure with a HA design, ensuring high availability.
No customizations. Since you control it, you can give a self-hosted indexer the shape and degree of customization that you want. In services where high degrees of customization are needed, working with a self-managed service can reduce the workload for the client.	We tackle customizability by integrating the Zephyr VM, our WebAssembly VM. Users who wish to have full customizability (and also additional perks) can write their logic in any WASM-compatible language and deploy it to Mercury's cloud execution environment. This effectively allows anyone to create their indexer, while still leveraging our database and API.

---

Now that you have a clearer overview of Mercury, let's start by diving into what subscriptions are and how to create them. Before though, you can take a look at the pricing plan we have.