Growing the database

Required

• Fit the connection budget to the autoscaling maximum

  SCL-23

  The maximum number of copies of each process type times its pool size, summed over all types, stays below the database's connection limit. Check it whenever a maximum or a pool size changes.

• Change large tables in small batches

  SCL-27

  Update, delete or copy many rows in batches of at most 10,000, each in its own short transaction, with a pause between them. Never touch millions of rows in one statement.

Recommended

• Keep reports and exports off the primary

  SCL-24

  Run long reads, such as reports, exports and analytics, on a replica or a separate copy. The primary serves the app's own reads and writes.

• Partition tables that outgrow memory

  SCL-25

  Split a table into partitions by date or tenant once it is larger than the database server's memory. Drop or detach old partitions instead of deleting their rows.

• Move finished rows out of hot tables

  SCL-26

  Move rows the app no longer changes, such as orders closed more than 2 years ago, into an archive table or store. The hot table keeps what daily work touches.

• Watch size and growth

  SCL-36

  Track how fast the database and its biggest tables grow, and alert well before disk or plan limits are reached.

Avoid

• Splitting one database across servers too early

  SCL-28

  Do not spread one database across several servers while a larger server, replicas, partitions or archiving can still carry the load.