关于Corda的H2数据库支撑千万级长期交易存储能力的技术问询

Let's break this down clearly, covering both your questions about H2's limits and whether your target scale is feasible:

1. H2 Database's Transaction Storage Upper Limit #

H2 doesn't have a hard-coded maximum number of transactions it can store. The actual practical limit depends on three core factors:

• Available disk space: The total size of your transactions (including contract hashes, Corda's metadata like timestamps, transaction IDs, and participant details) will dictate how much disk you need. We'll calculate this for your use case below.
• Memory allocation: H2 relies heavily on in-memory caching for performance. If you don't allocate enough heap/cache space, it will start swapping to disk—killing performance long before you hit physical disk limits.
• Performance thresholds: Even with enough resources, H2 is a lightweight embedded database, not built for enterprise-grade throughput. It will start struggling with write/query latency once you reach large scales, regardless of disk space.

2. Can Corda + H2 Support 10M Daily Transactions (3-Year Retention)? #

First, let's run the numbers to put your scale in perspective:

• Total transactions over 3 years: ~10M * 365 * 3 = 109.5 billion transactions
• Estimated storage per transaction: A SHA-256 hash is 32 bytes, plus Corda's mandatory metadata (transaction ID, timestamp, participant info, etc.) lets us ballpark ~100 bytes per transaction. Total storage needed: ~109.5B * 100 bytes = ~1.07 TB

Disk space isn't the problem here—but H2's design and performance constraints make this scale unfeasible for production:

• Concurrency bottlenecks: H2's multi-version concurrency control (MVCC) isn't optimized for sustained high-volume writes like 10M transactions per day. You'll face severe lock contention, write timeouts, and growing latency as the dataset balloons.
• Embedded database limitations: H2 is intended for development/testing, not production clusters. It handles multi-threaded or high-concurrency writes poorly, and its file-based storage can become corrupted under heavy load.
• Maintenance headaches: At 100B+ transactions, querying historical data (like looking up an old contract hash) will be extremely slow—even with indexing, H2's optimization tools are far less robust than enterprise databases.
• Corda's intended production stack: While H2 is the default for development, Corda fully supports enterprise-grade databases (PostgreSQL, Oracle, SQL Server) in production. These are purpose-built to handle exactly the scale you're targeting.

If You Must Use H2 (Strongly Not Recommended) #

If you're stuck using H2 for some reason, you'd need aggressive workarounds to have any shot at stability:

• Tune H2's configuration: Increase cache size (DB_CACHE_SIZE), enable write-ahead logging optimizations, and explicitly use MVCC mode.
• Implement data archiving: Regularly move old transactions (e.g., older than 6 months) to a separate storage system (like object storage) and only keep recent data in H2.
• Shard the database: Split transactions into separate H2 files by date or transaction type, though this adds massive complexity to your Corda node's data access layer.

Even with these steps, H2 is not a reliable choice for 3 years of 10M daily transactions. You'll almost certainly face performance degradation, data corruption risks, and operational nightmares.

内容的提问来源于stack exchange，提问作者Steve Xiao