VBR v13 defaults to PostgreSQL for all new installations. If you're still on SQL Express or a licensed SQL Server, there's a migration ahead of you. If you've already migrated and things feel slower than expected, that's almost always a tuning issue. The default PostgreSQL config is built for general workloads, not VBR's specific access patterns. This article covers the migration, what the Veeam tuning command actually does, vacuum behavior, monitoring queries, and what changes at MSP scale past 50 tenants.

1. Should You Migrate? Decision Guide

2. The Migration Process

It's a backup and restore cycle, not a live database conversion. Your jobs, schedules, infrastructure settings, and credentials all carry over. The only thing that changes is which database engine VBR talks to.

1. **Install PostgreSQL.** Supported versions are 14 and later. The Veeam v13 ISO includes PostgreSQL 15.

2. **Create a configuration backup.** Main menu, Configuration Backup, Backup Now. Enable encryption. Without it, credentials are stored in clear text.

3. **Restore with Migration mode.** Main menu, Configuration Restore, Migrate. Select the PostgreSQL instance as the target.

4. **Run the tuning command.** See Section 3. This is the step most guides skip entirely.

5. **Re-enable jobs.** Jobs are disabled during migration. Verify console connects cleanly before re-enabling everything.

Exclude PostgreSQL from antivirus real-time scanning. This is documented in the Veeam PostgreSQL deployment guide and is responsible for the majority of post migration performance complaints. Add the PostgreSQL data directory and binary directory to your antivirus exclusions before you conclude there's a performance problem.

3. The Tuning Command

Set-VBRPSQLDatabaseServerLimits calculates PostgreSQL configuration values based on your server's actual hardware and outputs them to a file. It's not optional on any environment with meaningful scale. The default PostgreSQL configuration allocates minimal shared memory and conservative connection limits. VBR reads heavily during reporting and writes heavily during job runs, with bursts of concurrent queries the default configuration throttles unnecessarily.

POWERSHELL: Generate and apply PostgreSQL tuning for VBR

Connect-VBRServer -Server "localhost"

# Generate recommended values based on this server's hardware
Set-VBRPSQLDatabaseServerLimits -DumpToFile "C:\temp\pg-recommended.txt"

Disconnect-VBRServer

# Review the output then apply values to postgresql.auto.conf
# Key parameters tuned:
# shared_buffers, effective_cache_size, maintenance_work_mem
# max_connections, work_mem, wal_buffers

# Example values (use actual values from your output file)
$pgDataDir = "C:\Program Files\PostgreSQL\15\data"
Add-Content "$pgDataDir\postgresql.auto.conf" "shared_buffers = 2GB"
Add-Content "$pgDataDir\postgresql.auto.conf" "max_connections = 200"

# Reload PostgreSQL (no restart needed for most parameters) # pg_ctl reload -D "C:\Program Files\PostgreSQL\15\data"

4. Vacuum: What It Is and Why It Matters

PostgreSQL uses MVCC for transaction isolation. When a row is updated or deleted, the old version isn't removed immediately. It's marked as dead and left in place until VACUUM cleans it up. A database with frequent updates like VBR's job session tables accumulates dead rows until VACUUM runs. PostgreSQL runs autovacuum automatically in the background and handles this without intervention for most environments.

You need to actively think about vacuum when: the VBR database is very large after migrating from a heavily used SQL Express instance; file-to-tape jobs are running (they write one metadata record per file, and a large NAS job can generate millions of rows faster than autovacuum's default schedule handles); or job history queries in the VBR console are slow.

SQL: Check for table bloat and vacuum status in the VBR database

-- Check tables with the most dead rows
SELECT relname AS table_name, n_live_tup, n_dead_tup,
ROUND(n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 1) AS dead_pct,
last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY n_dead_tup DESC LIMIT 20;

-- Run VACUUM manually on bloated tables VACUUM ANALYZE [table_name];

5. Monitoring Queries

SQL: Active queries and connection count

-- Active connections and what they're doing
SELECT pid, usename, state, query_start,
EXTRACT(EPOCH FROM (now() - query_start)) AS seconds,
LEFT(query, 120) AS query_preview
FROM pg_stat_activity
WHERE datname = 'VeeamBackup' AND state != 'idle'
ORDER BY query_start;

-- Connection count vs max_connections
SELECT COUNT(*) AS current,
(SELECT setting::int FROM pg_settings WHERE name = 'max_connections') AS max,
ROUND(COUNT(*)::numeric /
(SELECT setting::int FROM pg_settings WHERE name = 'max_connections') * 100, 1) AS pct FROM pg_stat_activity WHERE datname = 'VeeamBackup';

6. Performance at Scale: Past 50 Tenants

Connection Saturation

VBR opens database connections for each backup job, restore session, and concurrent management operation. In a busy MSP environment with hundreds of simultaneous tenant jobs, the default max_connections value fills up. When it does, new connection attempts fail and VBR jobs start failing with database errors that look like infrastructure problems but are actually database limits.

Two-part solution: set max_connections based on Set-VBRPSQLDatabaseServerLimits output, and consider deploying PgBouncer as a connection pooler in front of PostgreSQL. PgBouncer lets VBR handle far more concurrent operations than max_connections alone would allow.

Tape Metadata Bloat

File-to-tape jobs write one metadata record per file into the VBR database. A NAS job backing up a share with 10 million files generates 10 million metadata rows. These accumulate faster than autovacuum's default schedule can clean them. Fixes: increase autovacuum aggressiveness on the tape catalog tables, run scheduled manual VACUUM ANALYZE during off-peak hours, and use VBR's tape catalog management settings to control retention of old catalog entries.

Key Takeaways

• PostgreSQL is the default for all new VBR v13 installations and the only option for the Linux Software Appliance. Veeam's stated direction is to phase out SQL Server as a supported VBR database. Plan the migration even if you don't execute it now.

• Migration is a backup and restore cycle. Jobs, schedules, infrastructure, and credentials all carry over. Only the database engine changes.

• Run Set-VBRPSQLDatabaseServerLimits and apply the output to postgresql.auto.conf after migrating. The default config is not tuned for VBR. Skipping this is the most common reason post migration performance is worse than SQL Server.

• Exclude the PostgreSQL data directory and binary directory from antivirus real time scanning. This is documented by Veeam and is responsible for most post migration performance complaints.

• PostgreSQL autovacuum handles dead row cleanup automatically for most environments. You need manual VACUUM when running file-to-tape workloads with millions of files or when job history queries in the console are slow.

• At MSP scale with 50+ tenants, watch max_connections. When it fills up, VBR jobs fail with database errors. Set max_connections from Set-VBRPSQLDatabaseServerLimits output and consider PgBouncer.

Veeam v13 Series | Migration, Vacuum, Monitoring, and MSP Scale

Full article @ anystackarchitect.com