[Blog](/blog/.md) # How Goldsky Serves Billions of Sub-10 ms Lookups from One Copy of the Chain Goldsky built Prism, a geo-replicated blockchain data lake, on Tigris. TAG, the Tigris Acceleration Gateway, serves historical point lookups in about 9 ms without a database copy in every region. Author [![Katie Schilling](https://avatars.githubusercontent.com/u/8411213?s=400\&u=762567c65decb82e1433a7d1c42a2ffdcc59a125\&v=4)](https://www.linkedin.com/in/katieschilling) [Katie Schilling](https://www.linkedin.com/in/katieschilling) DevEx Enthusiast Published2026-10-06 Reading5 min Tags [Customers](/blog/tags/customers/.md)[Data Lake](/blog/tags/data-lake/.md)[Performance](/blog/tags/performance/.md)+1 Contents * [One chain, stored once](#one-chain-stored-once) * [The architecture](#the-architecture) * [TAG: database latency without the database](#tag-database-latency-without-the-database) * [Why Tigris](#why-tigris) * [Results](#results) * [Conclusion: one copy is enough](#conclusion-one-copy-is-enough) *Goldsky published their own deep dive on this architecture: [Prism: A Geo-Replicated Data Lake Serving Billions of <10 ms Point Lookups](https://goldsky.com/blog/prism-geo-replicated-data-lake-tigris-vortex-slatedb). Thank you to Håkon, Jeff, and the Goldsky team for writing about us. This post is the Tigris side of the same story.* A wallet that takes a second to show a balance feels broken. A trading app that reads stale state loses money. For teams building onchain, the read path is the product. [Goldsky](https://goldsky.com/) provides that read path with APIs, subgraphs, and streaming pipelines for teams building onchain. Until now, those teams could either pay a provider for every call and watch the bill climb with traffic, or run the whole setup themselves and own the latency. Their new data lake, Prism, answers billions of point lookups in under 10 ms from a single copy of each chain stored on Tigris. ## One chain, stored once[​](#one-chain-stored-once "Direct link to One chain, stored once") Blockchain data outgrows general-purpose databases quickly. Solana alone holds close to 600 billion transactions and more than 600 TB, and it grows by thousands of transactions every second. Querying nodes directly works, but the bill grows with every request. Analytical engines hold the data but cannot answer a real-time API call in under 10 ms. The usual fix is a database in every region, each with its own copy of the chain. Goldsky went the other way. In their words, "Prism is Goldsky's data lake for blockchain data. It stores each chain once and serves all of our products from the same files." A chain writer batches blocks into [Vortex](https://vortex.dev/) files and writes them to Tigris, with a [SlateDB](https://slatedb.io/) index stored next to the data. Turbo pipelines, Edge RPC, Boost, and subgraphs all read those same bytes. ## The architecture[​](#the-architecture "Direct link to The architecture") FIG 01Prism writes each chain once to Tigris and reads through memory, then TAG, then the bucket ``` ┌────────────────────────────────┐ ┌──▶│ batch of blocks, 1 Vortex file │───┐ ┌──────────────────────────┐ ┌───────────┐ ┌────────┐ │ └────────────────────────────────┘ │ │ Tigris bucket │ │ chain RPC │────▶│ writer │────┤ ├──▶│ global, no egress fees │ └───────────┘ └────────┘ │ ┌────────────────────────────────┐ │ │ each chain stored once │ ├──▶│ SlateDB index │───┘ └──────────────────────────┘ │ └────────────────────────────────┘ ▲ │ notify tip window │ │ │ <1% of reads ▼ │ 10 to 800 ms ┌────────────────────────────┐ ┌────────────────────────┐ │ │ reader │ miss │ TAG cache │ miss │ request ─────────▶│ tip window in memory │─────────▶│ gp3 in region │──────┘ │ ~90% of reads < 1 ms │ │ ~9% of reads ~9 ms │ └────────────────────────────┘ └────────────────────────┘ ``` A request falls through three tiers, and most never touch storage at all. About 90% are answered from the reader's tip window in memory in under 1 ms. About 9% miss memory and are served by the [TAG](https://github.com/tigrisdata/tag) cache in the same region in roughly 9 ms. Under 1% reach the Tigris bucket, at 10 to 800 ms. Vortex makes the hot tier larger than it looks. It keeps the same compressed layout in memory as on disk, so a reader holds roughly ten times more data per GB of RAM than it would with Parquet decompressed into Arrow. On a cold miss, Prism fetches the surrounding data too, so the next lookup for that range is warm. ## TAG: database latency without the database[​](#tag-database-latency-without-the-database "Direct link to TAG: database latency without the database") The warm tier is what makes one copy of the chain enough. [TAG](https://www.tigrisdata.com/docs/acceleration-gateway/), the Tigris Acceleration Gateway, is an open source, S3-compatible caching proxy. Goldsky's readers point their S3 client at TAG instead of at the bucket, and TAG keeps the objects each region actually reads on local NVMe. Goldsky uses it so that most reads that miss memory are served from that cache and never reach object storage. That gives Goldsky three things: * **History reads at about 9 ms.** That is the average S3 GetObject through TAG, served out of object storage rather than a database. * **No second copy to run.** The bucket stays the source of truth. Writes, deletes, and copies invalidate cached entries right away, so there is no replica to keep in sync. * **No new client.** Prism already spoke S3. TAG was an endpoint change. ## Why Tigris[​](#why-tigris "Direct link to Why Tigris") Goldsky names two reasons. Prism is an extremely egress-heavy workload, and Tigris does not charge egress fees. And of all the object storage providers they tried, Tigris "offered the most stable performance" for the workload. Without Tigris, the economics of this project likely wouldn't work at all. Tigris's way of doing things enabled the project to begin with. Jeff LingCo-founder and CTO, Goldsky ![Jeff Ling](/blog/assets/images/jeff-ling-b237f79320c9eb52ae05396cbf983b4e.webp) When your customers operate in highly regulated environments, trust is the whole product, and nobody hands it over on a handshake. Goldsky didn't either. Before signing with Tigris, they ran the real workload in the shadow for months. "We ran a shadow deployment with not much of Tigris' involvement. We just ran it," says Jeff Ling, Goldsky's co-founder and CTO. "It's length of testing time, plus a lack of random things happening, that lets us feel good about using the service." ## Results[​](#results "Direct link to Results") Prism is in production today, serving from thousands to hundreds of thousands of requests per second per chain. | Chain | Requests served at tip | Tip lookup | Historical p50 | | --------------- | ---------------------- | ---------- | -------------- | | Ethereum | 67% | 1.4 ms | 3.6 ms | | Robinhood Chain | \~90% | 0.2 ms | 11 ms | | Optimism | 49% | 0.8 ms | 17 ms | The savings reach Goldsky's customers too. Goldsky's own indexing services see cache hit rates up to 99% on Prism. One customer that turned on Prism caching through Boost cut upstream RPC usage from about 200 million requests a day to 80 million, saving five figures a month. ## Conclusion: one copy is enough[​](#conclusion-one-copy-is-enough "Direct link to Conclusion: one copy is enough") Goldsky did not have to choose between a slow bucket and a fleet of regional databases. Each chain lives once on Tigris, the tip lives in memory, and TAG covers the history in between. So when the next bank decides it is time to go onchain, Goldsky is ready for them. Put a cache in front of your bucket TAG is an open source, S3-compatible caching proxy for Tigris. Point your S3 client at it and keep your code as it is. [Read the TAG quickstart→](https://www.tigrisdata.com/docs/acceleration-gateway/quickstart/) ## Share [X](https://twitter.com/intent/tweet?text=Check%20out%20this%20post%20on%20the%20%40tigrisdata%20blog%3A%20How%20Goldsky%20Serves%20Billions%20of%20Sub-10%20ms%20Lookups%20from%20One%20Copy%20of%20the%20Chain%0A%0A\&url=https%3A%2F%2Fwww.tigrisdata.com%2Fblog%2Fcase-study-goldsky)[Hacker News](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fwww.tigrisdata.com%2Fblog%2Fcase-study-goldsky\&t=How%20Goldsky%20Serves%20Billions%20of%20Sub-10%20ms%20Lookups%20from%20One%20Copy%20of%20the%20Chain)[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.tigrisdata.com%2Fblog%2Fcase-study-goldsky)[Email](mailto:?subject=How%20Goldsky%20Serves%20Billions%20of%20Sub-10%20ms%20Lookups%20from%20One%20Copy%20of%20the%20Chain\&body=Hey!%0A%0ACheck%20out%20this%20article%20on%20the%20Tigris%20blog%3A%20https%3A%2F%2Fwww.tigrisdata.com%2Fblog%2Fcase-study-goldsky)Copy link