Running Primavera P6 on Microsoft SQL Server: What You Need to Know Before You Start

Primavera P6 carries Oracle's name, but a growing share of organizations run it on Microsoft SQL Server — and often for good reason. Many shops already own SQL Server licensing, already have DBAs who live in the Microsoft stack, and would rather not take on a separate Oracle database estate just to run one application. SQL Server is a first-class, fully supported backend for P6, not a fallback.

It runs perfectly well — as long as you respect a handful of rules that can quietly derail an installation or upgrade if you miss them. Here's a practical rundown of the requirements, hard limits, and sizing advice for pairing P6 EPPM with SQL Server.

The non-negotiable requirements

A few settings simply have to be in place before P6 will cooperate:

• SQL authentication must be enabled, and you'll need the sa password on hand — it's required for installing, upgrading, and migrating the P6 schema.
• FILESTREAM must be enabled on the SQL Server instance.
• SQL Server Agent must start automatically and run continuously. The P6 schema installation adds two Agent jobs per database, so this isn't optional.

These are the ones people forget, then spend an afternoon debugging a failed install script over.

Naming and password gotchas

Two easy-to-miss rules that will break the installation scripts:

• Database names cannot contain a dash. Underscores are fine, so my_p6_db works but my-p6-db doesn't.
• Database passwords cannot contain special characters. Avoid all of these: { } [ ] : ; , . ? ! @ # $ % ^ & * ( ) - _ | / \ ~ `. Stick to letters and numbers to stay out of trouble.

Collation: case-insensitive only

P6 does not support case-sensitive (CS) collation. When you create the database, either leave the default SQL_Latin1_General_CP1_CI_AS as-is or pick another collation with _CI_ in the name — never _CS_.

The good news is that internationalization is well covered: Cyrillic, Japanese, Chinese (PRC), Chinese (Taiwan), and Western European collations are all supported on their respective OS locales.

What's supported — and what isn't

This is where a lot of cloud migrations go sideways:

• SQL clustering is not supported. Database clustering only works with Oracle databases (Oracle Doc ID 2113800.1).
• Azure SQL Managed Instance (PaaS) is not supported. But SQL Server on an Azure VM (IaaS) is.

If you're unsure which flavor of Azure you're on, run this query:

SELECT filename FROM sysdatabases WHERE name = 'master';

If it returns a normal Windows path like C:\Program Files\..., you're on a supported setup. If it returns something like https://servername/storage/..., you're on a Managed Instance — which won't work.

Also worth noting: Oracle Cloud Connect, which can help in high-latency scenarios, is only supported on Oracle databases, not SQL Server.

Version compatibility

Match your P6 version to a supported SQL Server release:

For any SQL Server 2019 or later, Oracle recommends switching on LEGACY_CARDINALITY_ESTIMATION. Hardened SQL Server 2019 environments are also supported.

A word on SQL Express

SQL Server Express sits in a gray zone — it's neither officially supported nor officially rejected. You can use it, but the limitations are real: max 4 CPU cores, ~1.4 GB RAM, 10 GB database size, and no SQL Server Agent. Since P6 depends on the Agent for its scheduled jobs, you'll need a workaround if you go this route. Fine for a lab or proof of concept; not something to build production on.

Migrations go both ways

If you're switching database platforms, P6 EPPM supports schema conversion and migration from Oracle to SQL Server and from SQL Server to Oracle. You're not locked in either direction.

Hardware sizing and performance

Rough starting points for provisioning the database server:

• Small deployment: 4 CPU, 16 GB RAM, 500 GB storage (on Azure, a DS12_v2 VM with 4 vCPU fits).
• Medium deployment: 6 CPU, 24 GB RAM, 1000 GB storage.

The single most underrated factor here is network latency. Keep it as low as possible between the P6 Professional clients, the P6 application server, and the database server. High latency doesn't just make things slow — it produces genuine application errors and user frustration.