Considerations When Scaling with Multiple Source Accounts

While distributing load across multiple source accounts is an effective way to increase throughput, it’s important to strike a balance. Simply creating millions of unique accounts to maximize parallelism introduces its own set of challenges.

🚫 The Problem with Excessive Account Creation

Creating millions of distinct @world:{random} accounts for the sake of parallelism:

• Bloats the database: Each account adds a row to the accounts table, even if used just once. Over time, this results in a massive number of mostly inactive or redundant rows.

• Increases storage and index overhead: PostgreSQL will need to maintain indexes and stats for all these accounts, impacting query performance and increasing I/O.

• Adds management complexity: Monitoring, auditing, and querying such a large volume of "throwaway" accounts becomes harder and less meaningful.

📉 The Real Bottleneck: Parallelism Limits

Even if you scale horizontally by adding accounts, you are still fundamentally bound by:

• PostgreSQL’s connection concurrency limits (number of active writers).

• CPU and I/O capacity of the database server.

• Row-level lock granularity, which is optimized but not unlimited.

✅ Practical Recommendation

Rather than starting with a massive pool of random source accounts, we recommend a staged, controlled approach:

• Start with 20 @world:{random} accounts.

  • This already gives you 20x parallelism over a single account bottleneck.

  • Most applications see significant throughput gains at this level.

• Monitor performance and scale incrementally.

  • If performance remains a constraint, increase the pool gradually (e.g., 50, 100).

  • Each step should be validated with actual throughput and resource metrics.

This keeps your system performant, predictable, and easier to maintain.

📌 Summary