Database configuration

Before creating a database, we recommend that you review our recommendations.

Database disk I/O management

Reliable disk performance is critical for SQL Server. Ensure the database has enough throughput and space for both day-to-day workload and future growth.

On-premises / EC2: Separate data, log, and TempDB onto different volumes. Use RAID10 for performance and resilience. Pre-size files to reduce growth events.
Amazon RDS: Choose the right storage type (gp3 for most workloads, io1/io2 for high IOPS). Enable storage autoscaling to prevent space issues. Monitor CloudWatch for latency, IOPS, and free space.
Azure SQL: Select the correct service tier (General Purpose, Business Critical, Hyperscale). Define MAXSIZE with headroom for growth. Monitor Azure metrics for I/O and storage use.

See Server Hardware Requirements and Planning for Verint's recommended optimal database sizing.

Database memory

Memory sizing should ensure most active data fits into cache while leaving enough headroom for the operating system and platform services.

On-premises / EC2: Set maximum server memory so the OS has at least 10–20% of total RAM available. Avoid co-hosting SQL Server with other heavy services.
Amazon RDS: Select an instance class with sufficient RAM for the workload. Adjust memory settings through DB parameter groups if needed.
Azure SQL: Memory is tied to service tier and vCores. If you observe frequent I/O pressure, scale up to a larger tier or vCore count.

Collation

Server collation is the sort order and the case sensitivity of the data within the databases. Setting the collation at the installation time for the default collation of the databases is the best time. This is so that all of the system databases (master, msdb, model and tempdb) are created with the same sort order that the user databases would use. This allows for better interoperability.

If you use a case-sensitive database, there might be issues with names matching in sign-in or places that use a name on the URL to identify the location (groups, users, or blogs).

Choose collation before creating databases (and at instance creation for on-prem/RDS; at DB creation for Azure SQL Database; at instance creation for Managed Instance).
Keep TempDB/user DBs consistent; case-sensitive collations can break name comparisons in URLs/logins.
For Azure SQL Database, there is no “server” you control—set the collation on each DB and be consistent across environments.

Initial database size

Pre-size data and log files so growth events are rare during normal operations, with enough headroom for 6–12 months of projected growth. Use fixed MB sizes (not %) and size the log for peak burst and log backup cadence. In managed platforms, you don’t control files directly—pick MAXSIZE (Azure SQL) or instance storage with autoscaling (RDS) to prevent space-related outages.

Plan for at least 6–12 months of growth when setting initial size.
Data files: start larger rather than smaller to avoid frequent expansions.
Log files: size for peak workload so they rarely need to grow.
On-premises / RDS: use fixed growth in MB rather than percentages, with increments large enough to avoid dozens of small growth events.
Azure SQL: set MAXSIZE with growth headroom. The platform manages file growth within that limit.

Database sizing formula

Use Server Hardware Requirements and Planning to approximate the total amount of storage required when sizing the disk space needed for your SQL Server database.

The formula assumes the default set of user profile properties and on average one revision of a wiki document.

The metadata factor % is a value that adds a percentage of the core data to the total size.

Sizing formula = (Number of Items * Item Storage Required) * 112%

For example, assuming 100,000 users at 3.04kb per-user, you would plan for 296.88MB of storage with an additional 35.6MB of metadata for a total storage requirement of 332.5MB.

Each configuration is unique. Some installations will have more user storage with custom user properties, whereas other installations will have multiple revisions of Wiki documents.

On-premises / RDS: monitor actual growth and adjust file sizes or storage allocation regularly.
Azure SQL: choose service tier and MAXSIZE based on projected needs; scale up if you consistently approach limits.

Autogrowth SQL settings

Use the sizing recommendations in database sizing formula when creating your data file. Autogrowth should be a safety net, not the primary growth method.

- Pre-size data and log files whenever possible.
- Use fixed MB increments rather than percentages.
- As a general guideline:
  - Data files: set autogrowth between 256 MB and 1 GB.
  - Log files: set autogrowth between 128 MB and 512 MB.
- On-premises / RDS: review growth history periodically and adjust increments if growth events are frequent.
- Azure SQL: the platform manages file growth automatically up to the defined MAXSIZE.

Recommendations

Always keep free capacity available: 20–30% of storage for on-premises/RDS, or sufficient headroom in MAXSIZE/service tier for Azure SQL.
Monitor database size, growth, and I/O regularly.
Reassess capacity and configuration after major application changes or at least twice a year.