Summary: A lot of enterprise blockchain projects run into trouble when they don’t have a strong, searchable data layer. This guide is designed to help decision-makers navigate the process of creating and selecting a modern indexing stack that aligns with the landscape of 2025. We're talking about things like EIP‑4844 blobs, history expiry, and DA layers (like EigenDA and Celestia), along with high-throughput indexing frameworks. You’ll want to make sure your products, analytics, and compliance meet the mark--so you won’t find yourself stuck just six months down the line.

Enterprise Blockchain Indexing: Why Your Consulting Strategy Needs a Data Layer

If you're still relying on “an RPC endpoint + a database” for your blockchain data strategy, brace yourself for some real headaches. We’re talking about skyrocketing costs, missing historical data, and those long, drawn-out re-ingestion projects that can really put the brakes on things. Ever since the Dencun upgrade in March 2024 and the emergence of those modular data availability (DA) layers, everything’s been turned on its head. Layer 2 data is cheaper now, but it’s fleeting, and node clients are trending towards history expiration. Plus, the indexing game is shifting--it's all about streaming and parallel pipelines now, leaving those old-school poll-based RPC scrapers in the dust. For a deeper look, check out this article on CoinDesk.

This article dives into how 7Block Labs compiles and sources data layers that actually work in real-life situations. We'll chat about the latest updates, the refreshed toolbox, reliable reference architectures, and even a useful RFP checklist to help kick things off.

---

The 2025 reality: indexing isn’t optional--it’s survival

• L2 data is now stored in blobs! With EIP‑4844 coming into play, we've got these “blob” transactions that chill on the beacon chain for about two weeks--around 18 days, to be exact. They're a lot cheaper than calldata and get pruned, so if you miss capturing them, you might lose some key context. Each blob can fit a max payload of 4096 field elements, which is about 32 bytes each. This helps us keep our disk use nice and tidy. To sum it up, we’re limited to 16 blobs per block, which is roughly 2 MiB. For more info, check out eip4844.com.
• There’s been a pretty big shift with fees and traffic moving over to L2. After the Dencun update, we noticed a significant drop in L2 fees, which has really ramped up usage and pulled a lot of data towards L2s, steering it away from permanent calldata. Some analysis around Dencun showed that median L2 fees across major rollups fell by a whopping 50-99%. That’s fantastic news for users, but it might create a bit of a headache for those indexers who are a bit slower on the uptake. If you want to dive deeper into this, check out theblockbeats.info.
• Execution clients are starting to shed some old baggage. With EIP‑4444 (history expiry) in play, clients can now ditch block bodies and receipts that are over a year old. This is all part of the ongoing Pectra planning. So, practically speaking, your node might not keep serving that older history by default anymore. You'll need to rely on external archives or consider setting up your own data lake if you want to keep historical data on hand. For more info, check out eip.directory.
• The whole “Just call RPC” approach is running into some serious limitations. Managed endpoints tend to throttle range queries and they don’t automatically give you deep history or traces. For example, there are caps on eth_getLogs, and AWS AMB has certain methods that only deal with recent data. So, if you're planning to store everything reliably with random RPC pulls, you could be facing some challenges. If you want to dive deeper into this, check out the Chainstack documentation.
• Archive nodes really pack a punch when it comes to storage. A modern Geth archive can easily chew up over 20 TB, and even the more streamlined clients like Erigon still require several terabytes for full or archive modes. So, if you're thinking that having “just one node” will meet all your analytics needs, you might want to think again. Check out the details over at geth.ethereum.org.

Bottom line: Businesses absolutely need a solid data layer that ticks all the boxes--collection, normalization, lineage, and delivery. It should be tailored for temporary L2 data while also ensuring a smooth L1 history.

---

What “a real data layer” means in 2025

Design to These Capabilities:

• User-Friendly Interface: Design a clean and straightforward layout that helps users effortlessly locate what they’re looking for.
• Scalability: Make sure the design can expand as user needs grow, handling heavier workloads and more users smoothly.
• Performance Optimization: Make sure loading times are fast and seamless, so users can jump into the content without any hassle.
• Cross-Platform Compatibility: It's important to ensure that the design not only looks fantastic but also works smoothly on different devices and operating systems.
• Accessibility Standards: Make sure to stick to best practices so that everyone, including folks with disabilities, can enjoy a fantastic experience.
• Security Features: Make sure to integrate solid security features that protect user data and keep it secure.
• Customizability: Let users adjust settings or layouts to fit their personal style, which makes the whole experience a lot more enjoyable.
• Integration Capabilities: Make it a breeze to connect with other tools and platforms, so your workflow runs smoothly without any hiccups.
• Analytics and Reporting: Dive into user behavior and app performance to gather insights that will help shape future enhancements.
• Feedback Mechanisms: Create simple ways for users to share their thoughts and experiences with you. This will help you keep improving the design over time.

1. Capture fast, losslessly, and once
   • Instead of sticking with one-off RPC calls, why not think about grabbing blocks, logs, traces, state diffs, and blob metadata as events? It’s way more effective to go for streaming or parallel extraction (like Firehose/Substreams or ArrowSquid) instead of just polling. With Substreams-powered pipelines, you can sync your subgraphs at lightning speed--about 100 times quicker than the old-school RPC indexing. Want to dive deeper? Check out the details here: (docs.thegraph.academy)
2. Getting Through Reorgs and Moving Forward
   • Be sure to back up cursored streams, allow for rewinding, and set up idempotent sinks. Given that DA blobs don’t last forever, it's super important to have a system in place that can automatically recover from any missed windows.

3. Normalize across chains

• It’s really important to have a consistent approach using a standard chain_id, clear and uniform address formats, nullable aliasing for those L2 to L1 mappings, and consistent block/time semantics. Don't forget to manage numeric precision (like uint256) properly in your data warehouses. Google’s Blockchain Analytics datasets use lossless string representations for EVM uint256 to keep that precision intact--definitely think about adopting a similar method in your model. Check it out here: (docs.cloud.google.com)

1. Serve both OLTP‑ish APIs and OLAP analytics
   • You really want to fuel your product APIs with quick Postgres or ClickHouse, while also sending that valuable data to warehouse tables (like Snowflake or BigQuery) for all your BI and data science requirements.
2. Plan for History Expiry and DA Diversity
   • Make sure to hang onto your own cold copies (think flat files or Parquet) of key block/trace data and DA commitments. Staying prepared is a smart move since your clients and DA tiers will evolve as time goes on.

---

The modern toolbox (and what it’s good for)

• Streaming Extraction and Parallel Indexing
  • StreamingFast Firehose + Substreams: This awesome combo operates on a push model to provide low-latency block data with reorg-safe cursors. You can send that data pretty much anywhere--Postgres, Kafka, or data warehouses. It was created in collaboration with The Graph and can be set up for each chain. Take a look here: (firehose.streamingfast.io).
  • The Graph Substreams for subgraphs: Looking to make your syncs quicker? Substreams are your answer! They feed subgraphs, which can boost their speed by up to 100 times in some scenarios! Check out all the details at (docs.thegraph.academy).
  • Subsquid (SQD) ArrowSquid: This tool focuses on near-real-time ingestion of unfinalized blocks, execution receipts, traces, and state diffs. It’s a solid choice with support for public archive gateways and multi-chain ETLs. Want to learn more? Check it out here: (docs.sqd.ai).
  • DipDup: Think of this as a smart indexer that grabs historical data from Subsquid gateways and effortlessly shifts to nodes to fetch the latest tip data. Interested? Check it out at (dipdup.io).

DA Layers and Why Your Indexers Should Pay Attention

• EIP‑4844 Blobs: These blobs are all about quickly grabbing L2 batch metadata and commitments, and they have a timeline of roughly 18 days. Want to learn more? Check it out here: (eip4844.com).
• Celestia DA: Thanks to data-availability sampling and namespaced Merkle trees, apps can easily access just the data they need from their own namespace. During testnets, they managed to achieve about 27 MB/s throughput, and there are some cool features coming up. It's worth thinking about integrating segregated namespaces into your schema. For more details, check out (docs.celestia.org).
• EigenDA: Exciting news from Eigen Labs! They’ve just launched EigenDA v2, boasting an impressive 100 MB/s mainnet throughput. If you're working with EigenDA, don’t forget to set up your L2 batch indexers to log those crucial DA transaction IDs, inclusion proofs, and service-level metadata. Think of this as a kind of provider service level objective (SLO) that you definitely want to stick to. For all the details, check it out here: (linkedin.com).
• Warehouses, lakes, and query fabrics
  • BigQuery public + Blockchain Analytics datasets: If you're looking to dig into multichain public history, these well-organized schemas and lossless EVM numerics are your best bet. They’re perfect for on-the-fly analytics and machine learning projects. Just a little tip--try to avoid that “RPC-as-warehouse” method. (cloud.google.com)
  • Snowflake + Dune Datashare: With this combo, you can tap into more than 1.5 million curated blockchain tables thanks to zero-copy shares. It's a solid choice for enterprise governance, and it makes replicating across regions super easy. (docs.dune.com)
  • ClickHouse for real-time OLAP: This one’s really been put to the test with blockchain workloads at scale. Goldsky is using ClickHouse and Redpanda for their multi-tenant streaming analytics, and companies like Nansen are experiencing major cost and performance improvements after moving away from traditional byte-scanned warehouses. (clickhouse.com)
• Managed the “stream‑to‑DB” products
  • Goldsky Mirror: This is an ultra-fast pipeline solution that grabs data from the blockchain and sends it straight to Postgres, ClickHouse, S3, or Kafka. It comes packed with typed transforms, snapshots, and pipelines defined in YAML, which makes it perfect for teams wanting to streamline their setup. You can see all the details here!
• Nodes--what they can and can’t do
  • Geth's archive is now over 20 TB on mainnet, so budget accordingly! While Erigon is a bit more efficient, it still ends up in the multi-TB range for full/archive nodes. Just a heads-up: use nodes for execution correctness and tracing close to the tip, but they aren’t your best bet for heavy historical analytics. (geth.ethereum.org)
  • Keep an eye on those managed RPC constraints--they can be tricky! A lot of providers set limits on log ranges, and some managed chains may only give you access to about 128 recent blocks for certain calls. So, it's really important to design your ingestion strategy considering these restrictions right from the get-go. (docs.chainstack.com)

---

Reference architecture: a production‑grade indexing data layer

1) Chain Ingestion (Streaming-First)

Chain Ingestion: Streaming-First Approach

So, here’s the lowdown on chain ingestion: we’re all about that streaming-first vibe.

• Firehose/Substreams are our first choice for every chain and L2. We’ve got them configured to send out:
  • Blocks, transactions, receipts, and logs
  • For EVM chains, we’re also grabbing traces and state diffs (shoutout to those awesome map/reduce modules)
  • And let’s not overlook the DA metadata: blob commitments for EIP‑4844, Celestia namespace IDs, and EigenDA batch IDs.

For those chains that don’t support Firehose, we can always count on Subsquid ArrowSquid or just use good ol’ native node subscriptions. Just keep in mind to stream everything through a message bus!

2) Normalization and Enrichment

• The Transform modules in Rust and TypeScript help us create various typed entities like Transfers, Swaps, Mints/Burns, Positions, and a few others.
• Now, when it comes to entity resolution:
  • We really need to normalize our addresses. This means we’re juggling both binary and hex columns while making sure we’re aligned with the chain_id and mapping between L2 and L1. For instance, we’re linking OP Stack batches to L1 blob transactions.
  • When dealing with BigInt, our goal is to ensure lossless storage. This means we keep both the canonical string and binary representations to dodge any precision problems in SQL. You can dive deeper into this topic in the documentation!

3) Storage Tiers

• Hot: ClickHouse is your go-to for real-time analytics, while Postgres shines when it comes to product APIs.
• Warm: Consider Snowflake or BigQuery for your cross-team business intelligence and machine learning needs.
• Cold: Object storage with Parquet or flat Firehose files is great for replays, backfills, and maintaining a clean history with expiry resilience.

4) Serving

• We offer Product APIs (GraphQL/REST) that seamlessly pull data from Postgres and ClickHouse.
• For BI and ML, we tap into warehouse shares like Snowflake Datashare or public datasets from BigQuery. Want to dive deeper? Check out the details here: (docs.dune.com).

5) Reliability and Governance

• Reorg Strategy: We’re on it with cursor checkpoints and rewind mechanisms to keep everything running like a well-oiled machine. This way, any reprocessing impacts are totally manageable and happen predictably.
• Lineage: Each data entity has its own data contracts, and we’re rolling out versioned Substreams packages along with a schema registry for all our transformations.
• Observability: Make sure to watch pipeline lag, track reorg events as they’re processed, and keep tabs on sink latency SLOs. And hey, don’t forget to set up alerts for any missed blob windows!

---

Scenario

You're operating a consumer app on Base and Optimism, and things are really taking off--low fees and a surge in volumes! Now, it’s time to dig deeper and get those real-time insights you need. You'll want to focus on user funnels, swap attribution, and keeping an eye out for any fraud signals.

• Ingest: We’re diving into how Substreams works with OP Stack L2s. What we want to do is snag some batch/sequence and blob metadata to make sure we keep tabs on that crucial L2 to L1 provenance.
• DA awareness: Logging blob commitments (EIP‑4844) is super important because data gets pruned after roughly 18 days. Your cold storage is there to keep the must-haves accessible for any replays. Take a look at it here: (eip4844.com).
• Query:
  • Dive into those “last 60 minutes” cohorts and funnel steps using ClickHouse.
  • If you’re looking for historical cross-chain comparisons without any duplication, Snowflake is your best bet through Dune Datashare. Check out more info here: (docs.dune.com).
• Why this works now: L2 fees are currently super low, which is awesome! Just remember, since calldata isn’t permanent anymore, your indexing has to be almost real-time and mindful of blobs to cover any gaps. You can check out more details here: (theblockbeats.info).

---

Scenario Overview

Picture this: a global brand that’s super into showering its customers with loyalty points! They’re rolling out these points across three of the hottest blockchain networks out there: Polygon PoS, Base, and Solana.

Compliance Requirements

To keep everything running without a hitch, the brand has to check off some key compliance requirements every month:

• Proof of Issuance/Burn: They need to provide a transparent record of how many points were handed out and burned each month. It’s all about maintaining a trustworthy ledger!
• Cross-Chain Balances: Since these points are scattered across various chains, they'll have to keep a sharp lookout on the balances for each one to make sure everything aligns perfectly.
• Suspicious-Activity Flags: They’ve got to keep an eye out for any suspicious activities that might hint at fraud or misuse of those loyalty points.

By sticking to these guidelines, the brand can keep trust and integrity alive in their loyalty program.

• Ingest:
  • Snag EVM chains using Firehose or Substreams (we’re talking about things like ERC‑20 Transfers, Mints/Burns, and those internal transfers based on traces)
  • Explore Solana with either Substreams or the Goldsky dataset sources
• Normalize:
  • Build a robust “TokenMovement” fact table that captures chain_id, program/contract, sender/receiver, amount_raw, decimals, and tx_hash.
  • Establish snapshotted supply tables (sorted by day) in the warehouse with incremental materializations.
• Serve:
  • Create finance reports in Snowflake (making secure shares for auditors); dashboards pull data from ClickHouse to keep everything running smoothly.
• Notes:
  • It's super easy to connect BigQuery or Snowflake with curated public datasets (think labels and decoded ABIs) without having to fiddle with that ETL stuff yourself. Check it out here: (cloud.google.com)

---

Scenario: Multi-Year EVM Traces for Adversarial Simulation and Risk Rules

When you're diving into adversarial simulation and getting your risk rules in place, it's super important to collect multi-year Earned Value Management (EVM) traces. Here are some key points to keep in mind:

Why Multi-Year EVM Traces?

Having EVM data from multiple years at your fingertips can seriously boost your analyses. It’s great for recognizing trends, identifying potential risks, and forecasting possible hiccups down the road.

Key Components to Collect

1. Performance Data: Check out the data that highlights how projects have been doing over time. This should cover both the metrics we planned for and the actual results we achieved.
2. Cost Data: Collect details on the actual costs compared to what was budgeted. It’s important to understand how well the project stuck to its budget from start to finish.
3. Schedule Data: Here, we’ll look at timelines, key milestones, and any hiccups that might have come up along the way.

How to Gather This Data

No need to stress; you can usually dig up this info in project management tools and software. Just be sure to take a look at:

• Project Management Software: Check out tools like Microsoft Project or Primavera; they probably have the data you're looking for.
• Internal Reports: Take a moment to go through any documents from previous projects. This might be stuff like status reports, performance reviews, and financial records.

Wrapping It Up

Once you've gathered this data, you'll be all set to run simulations on various adversarial scenarios and create some solid risk rules. Just keep in mind that the more detailed your EVM traces are, the more valuable insights you'll get. Enjoy diving into the analysis!

• Just a quick note: Many providers limit access to debug_trace* and deep history, so it’s smart to set up your own trace lake. You can find all the details here.
• Here’s the plan:
  • Think about using Firehose/Substreams or high-throughput client stacks to pull traces into Parquet format just once. It’ll make your life a lot easier.
  • If you absolutely need to run client nodes, gear up for some hefty storage requirements--like multi-TB for Geth/Erigon and batch export windows. Seriously, ad-hoc RPC tracing can turn into a real hassle! More info is available here.
• When it comes to querying:
  • Use ClickHouse for lightning-fast trace pattern searches, while keeping your warehouse for those long-term aggregations.

---

Emerging best practices we recommend (with specifics)

1. Prioritize “blob windows” as a key SLO

• Monitor “blob capture lag” and “blob miss rate” closely. Your DA-aware indexer should strive to keep lag between 1-2 blocks and ensure misses stay under 0.01% of batches. It’s a good idea to set up alerts if the lag exceeds 60 seconds, especially since blob pruning starts happening after around 18 days. (eip4844.com)

2) Consider streaming or parallel ingestion instead of polling

• With Substreams and Firehose pipelines, you can avoid the headaches that come with RPC polling and those annoying reorg blind spots. The community at The Graph has noticed some impressive sync speed boosts--up to 100× faster for specific workloads--just by making the switch from RPC-based subgraphs to Substreams. If you want to dive deeper, take a look here: (docs.thegraph.academy)

3) Design Schemas for Precision and Speed

• Make sure to keep binary addresses and hashes next to their hex versions for a smoother user experience. It’s also a good idea to store raw uint256 values as both a lossless string and in binary to ensure your calculations are spot on. To speed up rescans, try pre-computing day/hour partitions and rolling snapshots. If you need some solid advice, check out BigQuery’s lossless numerics guidance. It’s a great resource! (docs.cloud.google.com)

4) Keep hot OLAP separate from the curated warehouse

• Use ClickHouse (or a similar tool) to get those real-time metrics and funnels rolling. For broader enterprise needs, send off your carefully curated and well-documented tables to Snowflake or BigQuery. Or, if you prefer, you can share them via Dune Datashare to avoid the hassle of data duplication and ETL drift. Check out the details here: (docs.dune.com)

5) Budget for History Expiry

• Consider offering a one-year availability option for many clients. Keep those cold block/trace files and DA commitments handy; plus, get those replay jobs going that can effectively re-hydrate any downstream table (utilizing Substreams packages and the exact versioned transforms). Take a look at it here: (eip.directory)

1. Don't Depend on “Free” RPC for Big Tasks

• Keep an eye on the provider's log-range and timeout limits. Whenever you can, break your backfills into chunks that can be resumed. Also, it's a good idea to use archive gateways or Firehose rather than relying on eth_getLogs sweeps. Check out the details here.

7) DA Layer Posture Matters to Data, Too

• If your rollup is using Celestia, make sure you’re keeping an eye on those namespace IDs and proof artifacts. And if you're opting for EigenDA, don’t forget to save those batch references along with any SLO metadata from the provider. Just a little tip: marketing claims don’t hold the same weight as SLAs, so think of them as external dependencies that require your attention. For more info, check out the Celestia docs.

---

Buy vs. build: a short decision framework

• Have you thought about creating:
  • Your own product analytics? This way, you can keep an eye on usage, spot fraud and risk signals to tackle issues before they escalate, and implement latency-sensitive personalization to really boost user experience. Plus, adding sensitive cross-system joins will help improve data integration!
• When it comes to buying, here are a couple of things to keep an eye on:
  • Dive into historical public chain data at scale--BigQuery public datasets or Dune Datashare are great options.
  • Check out managed pipelines for common entities, especially if you’ve got a smaller team. Goldsky Mirror is a fantastic option for this.
• A hybrid approach is pretty popular these days:
  • Stream data over to ClickHouse for those speedy insights; sign up for Dune Datashare in Snowflake to make sure you’ve got everything covered; and don’t overlook keeping your own Firehose/Substreams transforms for those essential systems. You can find more details here.

---

KPIs and SLAs we hold our data layers to

• Freshness: Aim for 1-2 blocks when you're working with hot metrics, and try to wrap things up in under 60 seconds for those priority entities.
• Reorg tolerance: Make sure there’s an automatic rewind for at least N confirmations, but keep in mind that this can vary based on the specific chain.
• Backfill speed: Shoot for at least 2 million blocks per hour for each chain when you're in replay mode--ah, and definitely parallelize this for better efficiency!
• Blob capture miss rate: Keep that miss rate under 0.01% for L2 batches. Set up alerts if it gets to 0.1% sustained so you can jump on it quickly. For a deep dive, check out eip4844.com.
• Cost ceiling: Aim to keep costs below $X for every 1 million on-chain events processed--don’t forget to track this on a weekly basis!
• Data contracts: Be sure to use versioned schemas that include lineage and change-management gates to keep everything nice and organized.

---

RFP questions to ask any indexing vendor (or internal platform team)

• How do you go about capturing EIP‑4844 blobs? And when do you decide to mark them as durable, especially with that 18-day pruning window? I'd love to see some metrics while you're at it! (eip4844.com)
• What's your strategy for handling reorganizations? How deep can you rewind for each chain?
• Can you provide traces or state diffs at scale, or do you have to default to some ad-hoc RPC? If RPC is in the mix, what are your provider's range limits, and how do you manage chunking and resuming? (docs.chainstack.com)
• How do you make sure that uint256 values in your warehouse are spot on and don’t lose any precision? (docs.cloud.google.com)
• What kind of throughput have you clocked for backfills (in blocks per hour), and what's the cost per million events?
• How do you protect against history expiry (EIP‑4444) that could throw a wrench into backfills a year from now? (eip.directory)
• Which sinks do you think are top-tier (like Postgres, ClickHouse, S3, Snowflake/BigQuery)? Also, is it possible to define pipelines as code using versioned packages or YAML? (streamingfast.io)

---

Brief deep dive: why RPC is the wrong indexing substrate

RPC was really designed for node interaction rather than dealing with bulk analytics. Typically, providers set limits on the ranges for eth_getLogs, and if you're looking into deep history or debug_* functions, many managed services come with their own set of restrictions. Even if you're considering self-hosting, you'd have to deal with archive nodes that can take up a ton of space--like over 20 TB for Geth! So, you might find yourself building a data platform through a super narrow channel, which is going to be slow, fragile, and quite expensive. On top of that, you'll still need a streaming, parallel layer to manage scaling, plus a data warehouse that's equipped for lossless crypto numerics. If you're curious for more details, take a peek at the Chainstack docs.

---

The 7Block Labs point of view

• Start with streaming instead of relying on polling.
• Think of DA as a crucial part of your data model from the get-go, not just something to think about down the line.
• Keep those cold block/trace files handy--just remember that history will need to be managed and eventually expire everywhere.
• Distinguish between hot OLAP and your curated warehouse; avoid extra ETL if you’re already set up with Snowflake or BigQuery.
• Approach blob windows and reorganizations as key service level objectives (SLOs).

If you're getting ready to launch a new chain, diving into a data-heavy project, or troubleshooting that tricky RPC-scraper, you're in the right place. We’ll whip up a pipeline using Substreams or SQD, get your data into ClickHouse for real-time processing, and link up your Snowflake or BigQuery with neat, lossless tables. On top of that, we’ll set up some solid operational guardrails to make sure your analytics stay reliable even a year from now.

Let’s Make Your Data Layer Super Reliable!

---

Sources

• EIP‑4844 blobs: There’s some cool news about the pruning horizon, blob sizes, and what to expect for long-term capacity per block. Make sure to check it out at eip4844.com!
• Dencun's impact: Wondering how Dencun is changing the game for Layer 2 fees and activity? Get all the juicy details at theblockbeats.info.
• EIP‑4444: Want to know about history expiry and what’s in store for the Pectra era? Catch up on everything at eip.directory.
• RPC and managed endpoint limitations: Interested in the ins and outs of log ranges and the recent block limitations? Check it out at docs.chainstack.com.
• Archive node sizing: Geth and Erigon are in the spotlight when it comes to archive node sizing. Find all the details you need at geth.ethereum.org.
• Substreams/Firehose performance: Curious about the performance model and the sinks related to Substreams and Firehose? Dive into it at streamingfast.io.
• Subsquid ArrowSquid: Want to learn about real-time ingestion and public gateways, plus how it works with DipDup? Head over to docs.sqd.ai to get the scoop.
• BigQuery and Blockchain Analytics: If you love lossless numerics, you definitely don’t want to miss the datasets available at cloud.google.com.
• Snowflake Dune Datashare: Looking for some curated crypto data? Check out the Snowflake Dune Datashare for all the details at docs.dune.com.
• ClickHouse case studies: Explore how Nansen revamped their data infrastructure using ClickHouse Cloud by reading those case studies at clickhouse.com.

---