Benchmarks and metrics collection for launch blog post

Inizia dopo la Fase 2, utilizzando il lavoro di osservabilità in #7 e i dati sullo stato di salute di #16; esamina il livello API, go.mod e le misurazioni relative a SQLite descritte nell’issue. Esegui i benchmark sui dati di mainnet per un namespace reale e documenta i risultati relativi a storage, prestazioni, risorse, semplicità e affidabilità nel post del blog di lancio.

Summary

Once apex is functional end-to-end, collect concrete benchmarks and operational data for a single namespace to support a launch blog post. The post should tell the story of why apex exists, what problems it solves, and back it up with real numbers.

Data to collect

Storage

• Total celestia-node disk usage for the same height range (full node)
• Total apex disk usage for a single namespace over the same range
• Storage reduction ratio (e.g., "400GB → 2GB = 200x reduction")
• DB file size growth rate per day/week
• Breakdown: headers vs blob data vs indexes

Performance

• Backfill throughput: heights/sec, blobs/sec during historical sync
• blob.Get latency: apex (SQLite lookup) vs celestia-node (namespace scan)
• blob.GetAll latency at various heights (sparse vs dense namespace)
• blob.Subscribe end-to-end latency: new block on celestia → blob delivered to consumer
• Time to full sync from a given start height

Resource footprint

• Memory usage: idle, during backfill, during streaming
• CPU usage: idle, during backfill, during streaming
• Peak memory during heaviest operation
• Compare against celestia-node light/full node memory profile

Simplicity

• Lines of code: apex total vs celestia-node
• Dependencies: count of direct deps in go.mod (core module, excluding submit/)
• Binary size
• Config file: apex YAML vs celestia-node setup ceremony (init, keys, trusted hash, etc.)
• Time from git clone to serving blobs (setup friction)

Reliability

• Uptime over test period
• Sync gap recovery time
• Graceful restart time (shutdown → serving again)

Blog post outline

1. The problem — celestia-node stores everything, rollups need almost nothing. Hundreds of GB for a few namespaces worth 10-20GB.
2. What we tried / issues we hit — reference the celestia-node issues discovered during research:
   • 8-second blob retrieval times (celestia-node#4453)
   • BadgerDB corruption on ungraceful shutdown (celestia-node#3881)
   • Non-contiguous subscriptions (celestia-node#3578)
   • No namespace-scoped storage despite 3+ year roadmap item (celestia-node#2033)
   • Subscription buffer overflow with silent disconnect
   • <10% resource utilization during sync (celestia-node#4108)
3. The approach — lightweight namespace indexer, SQLite, pluggable fetcher, drop-in API compatibility
4. The numbers — storage, performance, memory, simplicity benchmarks from above
5. What's next — Fiber support, gRPC, tx submission, multi-account

When

After Phase 2 is complete (API layer working, can serve ev-node). Benchmarks should be run against mainnet data with a real namespace.

Related

• #7 — Observability (metrics infrastructure needed to collect this data)
• #16 — Health endpoints (uptime, sync state data source)