⚙️
Proof of Work
Case Studies
What was built, what broke, what changed, and what it looks like today, written from years of production engineering, not after-the-fact polish.
⚙️01
Indexing a Blockchain in Real Time, at ScaleA blockchain never pauses for maintenance. Here's how SupraScan's indexer stays caught up, decomposes every transaction into a dozen relational tables, and survives its own concurrency bugs without losing data.500–1,000 TPS Production Throughput15–20 ops/tx Write Fan-out4.01x → 1x Coordination Fix
case-studyarchitectureblockchain
🗄️02
Scaling a Blockchain Database From a Single Partition to 4.6 TBA partition strategy that worked in 2021 became a 10TB liability by 2026. Here's the five-stage evolution that got it back under control, the outage the last stage caused, and the storage arc from 10TB avoided to 4.6TB today.10 TB → 4.6 TB Database Size229 GB / 296 indexes Zero-Scan Indexes Found5 stages, 2021–2026 Partition Grain Changes
case-studypostgresqlpartitioning
📊03
Exact Analytics in 12KB: Hardening a Wallet-Uniqueness SystemHyperLogLog gets you exact distinct-wallet counts at near-zero memory cost. The hard part is not the algorithm, it's keeping it correct under concurrent production writes. Five real bugs, one week, five different ways correctness quietly slips.5 in 1 week Correctness Bugs Fixed12 KB Memory per Bucket29 hours Sealing Stall Incident
case-studyhyperloglogredis
🔒04
Concurrency Design Under High TPS: Moving Wallet Counters Off Database TriggersA 3-4 day indexer lag traced back to four wallets and a database trigger. The fix moved counting logic out of the database entirely, and a routine check-with-the-docs step turned up an architectural assumption that had been wrong all along.3–4 days Indexer Lag Incident3 tables, 3 migrations Triggers Removed100,000 concurrent tasks Validated Burst Capacity
case-studypostgresqlconcurrency
🧹05
Paying Down Three Years of JSONB DebtJSONB is the right tool for a blockchain's variable-shaped data, until it isn't. A tiered removal plan, twelve columns re-classified one by one, and three columns nobody's allowed to touch because another team reads them directly.12 JSONB Columns Classified4 Columns Removed (Tier 1)3 (external readers) Protected Columns
case-studypostgresqljsonb
🌐06
One Codebase, Five Blockchain EnvironmentsMainnet, testnet, a MultiVM devnet, and two microchains all run the same indexer and backend code. A self-hosted infrastructure migration proved the abstraction actually holds, not just on paper.5 Environments Served290 tables / 819 indexes Self-Hosted Migration Match5 Steps to Add an Environment
case-studyarchitecturemulti-environment
⚡07
From a Redis Relay to a Direct Feed: Rebuilding the Real-Time PipelineThe old real-time pipeline worked. It also had a hop nobody needed anymore. Ripping it out across five repos took verified-dead traffic checks, a careful merge order, and knowing exactly which lookalike code path to leave alone.60s → 230ms Cold-Start Latency5 Repos Migrated~1 second Upstream Reconnect Gap
case-studywebsocketsredis
📈08
What It Would Take to Hit 500K TX/Sec, and Why That's the Honest AnswerEvery scaling lever on the table, measured honestly, still lands 25x short of a 500,000 tx/sec target. Here's the capacity-planning math, and why the right answer was to say so instead of overselling a smaller win.110–118 TPS Planning Baseline2,000–20,000 TPS Combined Estimate (3 levers)~25x short Gap to 500K Target
case-studycapacity-planningsystems-design
🚦09
Becoming the Readiness Gate for Another Team's Scale-UpOne team validated their system could handle 100,000 concurrent tasks. They still wouldn't turn the dial on a live network until a different team's indexer proved it was ready. That's a real dependency, not a hypothetical one.100,000 concurrent tasks Validated Task Capacity4 wallets, 3–4 day lag Root IncidentCross-team launch dependency Gate Type
case-studycross-teamblockchain
🔮10
Built for a Multi-VM Future: The RPC v4 Readiness WorkA block that mixes Move and EVM transactions is coming. Scoping exactly what breaks across five layers of the stack, before the feature is fully live, is the actual work of readiness engineering.Move + EVM, more planned VMs Supported (Target)5 (types → UI) Layers TouchedFeature-flagged, testnet-first Rollout Pattern
case-studyblockchainmulti-vm
🔢11
A Type Migration Across Three Services: VARCHAR to BIGINT at ScaleThe migration itself was the easy part. The real risk was every downstream function quietly assuming a column would always come back as a string. Two hotfixes later, that assumption was gone.3 Services Coordinated2 Follow-up HotfixesVARCHAR → BIGINT Column Type Change
case-studypostgresqlschema-migration
🛡️12
A Reliability-Hardening Sprint: Isolation, Guardrails, and a Query Plan That Went From 45 Million to 206None of these fixes were triggered by an outage. Per-network cache isolation, timeouts on every resolver, dead-code removal, a partition-pruning fix with a genuinely startling before/after number, and a real external security report handled the right way.45M → 206 Query Plan Cost7, zero from an outage Fixes Shipped400GB+ partition Full Scan Avoided
case-studyreliabilitygraphql
Get new posts by email
New posts and case studies on PostgreSQL internals and production incidents, plus a short digest when new course modules go live. No spam, unsubscribe in one click.
Prefer a feed reader? Follow via RSS