How to Choose the Right Breeze Plan for a Database Server

How to Choose the Right Breeze Plan for a Database Server

Database servers have unique resource requirements compared to web or application servers. They demand fast storage I/O, sufficient RAM to hold working datasets in memory, and enough CPU to handle concurrent queries. Choosing the wrong Breeze plan for your database can lead to slow query performance, connection timeouts, and frustrated users. This guide helps you select the optimal plan based on your database workload.

Key Resources for Database Performance

Database performance depends on four primary resources, listed in order of typical impact:

1. RAM (Most Critical)

Databases perform best when the active working set fits entirely in memory. Disk reads are orders of magnitude slower than memory reads, even on NVMe storage:

• MySQL/MariaDB: The InnoDB buffer pool should hold your most-accessed tables. Set innodb_buffer_pool_size to 60-80% of available RAM.
• PostgreSQL: shared_buffers should be 25% of RAM, with the OS cache handling the rest. Total effective cache can use 75% of RAM.
• MongoDB: The WiredTiger cache defaults to 50% of RAM minus 1 GB. Ensure your indexes fit in memory.
• Redis: Your entire dataset lives in memory. Choose a plan with more RAM than your dataset size plus overhead.

2. Storage I/O

All Breeze plans use NVMe storage, which provides excellent I/O performance. However, disk size matters for databases because:

• Database files, WAL/redo logs, and temporary tables all consume disk space
• You need room for backups and point-in-time recovery files
• Leave at least 20% free space for maintenance operations like OPTIMIZE TABLE or VACUUM FULL

3. CPU

CPU cores become important with high concurrency. Complex queries, sorting, aggregation, and encryption all consume CPU:

• Read-heavy workloads with simple queries: 1-2 vCPUs may suffice
• Mixed read/write with moderate complexity: 2-4 vCPUs recommended
• OLAP or reporting queries with complex joins: 4+ vCPUs needed

4. Bandwidth

Database traffic is usually internal (between your app server and database server), but consider replication traffic if you run read replicas.

Sizing Guidelines by Workload

Workload              Recommended Plan    Notes
─────────────────────────────────────────────────────
Small blog/CMS        1-2 GB RAM          < 1 GB database size
Business application  4 GB RAM            1-10 GB database size
E-commerce store      8 GB RAM            10-50 GB database, many writes
SaaS platform         16+ GB RAM          50+ GB, high concurrency
Data analytics        16+ GB RAM, 4+ CPU  Large queries, aggregation

Estimating Your Database Size

If migrating an existing database, check its current size:

# MySQL/MariaDB - total database size
SELECT table_schema AS 'Database',
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)'
FROM information_schema.tables
GROUP BY table_schema;

# PostgreSQL - database size
SELECT pg_database.datname,
       pg_size_pretty(pg_database_size(pg_database.datname))
FROM pg_database;

Growth Planning

Project your database growth over the next 12 months:

• Review historical growth rates (how much has your database grown per month)
• Factor in new features or traffic increases planned for the coming year
• Choose a plan that accommodates projected size with at least 30% headroom
• Remember that upgrading your Breeze plan is easy — you can always start smaller and scale up

Monitoring After Deployment

Once your database is running, monitor these metrics to verify your plan is adequate:

• Buffer cache hit ratio: Should be above 99% for InnoDB and shared_buffers
• Disk I/O wait: Should stay below 10% on average
• Slow query log: Enable and review regularly for queries that need optimization
• Connection count: Ensure max_connections is not being reached
• Free disk space: Alert if it drops below 20%