How StitchDB runs databases of hundreds of GB to several TB: dedicated large-storage servers, partitioning, incremental backups, read replicas and early warnings.
Every StitchDB project is one Postgres database on one server. A single Postgres database on fast NVMe handles several terabytes and high query rates well, so large projects grow by moving to a bigger server, not by changing how your app works.
#What happens as a database grows
- Early warning. StitchDB tracks each database's size every day and forecasts when it will reach its plan's limit. Owners get an email 30, 14 and 7 days before; the usage page shows the forecast.
- A server that fits. When a project heads past about 200 GB, or past half of its shared server's disk, we suggest a dedicated large-storage server with its price. You choose; the project moves without downtime and its URLs, keys and connection strings stay the same.
- Moves check the room first. A move only starts when the target server has at least 1.5 × the database size free, and shows how long it will take.
- Tuned maintenance. Databases over 50 GB get autovacuum tuned for their big tables automatically, so large tables stay fast without manual settings.
#Dedicated large-storage servers
In Settings → Compute → Large storage (Scale and Enterprise) you pick a real server by the database size you need: servers with large local NVMe disks, or a server with attached network storage up to 10 TB. Prices are shown before you confirm.
#Partitioning huge tables
Tables that grow without limit (events, logs, metrics) should be partitioned by time. See Partitioning large tables: native partitioning plus pg_partman, maintained by a cron job, with old partitions dropped or archived.
#Backups and restores of large databases
- Incremental backups. Every server takes a full snapshot once a week and only the changed blocks every day in between, so daily backups stay fast and small. Daily backups are kept for 7 days, then one per week up to your plan's backup retention.
- The change log is continuous, so point-in-time recovery works exactly as for small projects.
- Daily restore points. Every project's daily backup is a restore point served from the server's snapshots and change log, so no multi-hour dump runs every night. Export the current data any time from the Backups page or with
stitchdb db dump. - Restore time grows with size. The Backups page shows an estimate before you start. As a guide: a few minutes for a few GB, roughly an hour per 100–200 GB.
#Reads at scale
Read replicas spread read traffic across servers and regions; writes stay on the primary.
#Beyond that
If your database needs more than the largest dedicated server offers, contact support and we will plan it with you.