Your contract events,
in your own Postgres.
Give it an event spec, a contract ID, and a stellar-rpc endpoint. Sorolog streams every Soroban event into your own PostgreSQL — one table per event, reliable and gap-free — from a single YAML manifest.
Hosted indexers are delayed, rate-limited, and keep your data on their side. Raw stellar-rpc leaves paging, the retention window and XDR decoding to you. SubQuery means projects and heavy ops. There was no declarative path to your events, in your Postgres, in plain SQL.
Declare it. The operator does the rest.
One Indexer resource describes what you want. A Kubernetes operator keeps it true — schema, tables, worker, status.
Write one manifest
Contracts, event-spec ref, RPC pool, storage — the whole setup.
kind: Indexer metadata: { name: usdc-stellar } spec: rpc: # health-checked failover - https://soroban-testnet.stellar.org contracts: - contractId: "CBIEL…DAMA" eventSpec: { configMapRef: usdc-events } startLedger: 0
The operator provisions
A reconcile loop turns the spec into running parts — and heals them.
Query plain SQL
Each event is a table in your Postgres. No API between you and your data.
-- one table per event SELECT "from", "to", amount FROM usdc_transfer WHERE amount > 1000000000 ORDER BY ledger DESC;
event spec in → tables out · empty events list = every event in the spec · startLedger: 0 backfills from the RPC retention window
Even if the network blips, no data is lost.
A poll-based backbone chosen for loss-free, self-healing ingestion — not just latency. Don't take our word for it: break something.
The last processed ledger lives in Postgres. After any crash it resumes exactly there.
Event inserts and cursor advance share one transaction — a commit, or nothing.
Ledgers are final the moment they close — what Sorolog writes never gets rolled back.
A passphrase-checked pool with rotation and backoff. A blip never becomes a gap.
A specific combination nobody else offers.
| Mercury | SubQuery | Raw RPC | Sorolog | |
|---|---|---|---|---|
| Data in your own DB | No | Via subquery-node | If you build it | ✓ Yes |
| Plain SQL access | GraphQL | GraphQL | Raw XDR/JSON | ✓ Yes |
| Retention & gap handling | Theirs | Yes | On you | ✓ Built-in |
| Setup effort | Low | Med–high | High | ✓ One YAML |
Honest positioning: Mercury stays great for hosted zero-ops indexing; SubQuery for multi-chain projects. Sorolog is for teams that want their own Postgres, plain SQL, and K8s-native ops — together.
One YAML. A running indexer.
Runs in your cluster. Your data never leaves it.
$ kubectl apply -f https://sorolog.com/install.yaml