Error 905 and 909: The Database Uses Features Your Edition Does Not Have

Fix it now

905 and 909 stop a database coming online because the edition you are starting it on cannot run something inside it. 905 names a partition function; 909 names an object using data compression or vardecimal. The database is intact. Ask the database what is in it before you buy anything, because the answer has changed since those messages were written.

SELECT feature_name FROM sys.dm_db_persisted_sku_features;
SELECT SERVERPROPERTY('Edition') AS TargetEdition, SERVERPROPERTY('ProductVersion') AS TargetVersion;

1. Run the view on the source while the database is still open somewhere that can open it. Every row is a feature recorded inside the database.
2. Check the target’s edition and version. From SQL Server 2016 Service Pack 1 onwards, Microsoft states those features except transparent data encryption became available across editions rather than Enterprise and Developer only.
3. If the target is a current Standard instance, compare the rows against its own editions table before assuming Enterprise is required. Partitioning, data compression, columnstore and In-Memory OLTP are all supported on Standard today.
4. If the target is Express, or an old build, remove the listed features on the source, take a fresh backup, and restore again.

The view needs a permission. Up to SQL Server 2019 that is VIEW DATABASE STATE on the database; from SQL Server 2022 it is VIEW DATABASE PERFORMANCE STATE. Without it you get an empty result, which reads exactly like “no blocking features” and is not.

If the database comes online on the target, you are done. If the view lists something the target genuinely cannot run, the next section covers what each entry means.

Why it happens

Some features leave a permanent mark inside the database rather than only in the instance that created it. Partitioned structures, certain compression and storage formats, change data capture, columnstore, In-Memory OLTP, transparent data encryption and multiple FILESTREAM containers are recorded in the database so that any engine opening it can see what it will be asked to do. sys.dm_db_persisted_sku_features lists exactly those marks, and when a target edition cannot run one, the check fails and the database is left offline before anything is read.

The two error numbers are more specific than they look. 905’s published text is that the database cannot be started in this edition because it contains a named partition function, and that only Enterprise edition supports partitioning. 909’s is that part or all of a named object is enabled with data compression or vardecimal storage format, and that those are only supported on Enterprise. 5069 is a companion, ALTER DATABASE statement failed, usually raised as the engine tried to bring the database online.

Both message texts are stale, and this is the single most important thing to know before spending money. Microsoft states that starting with SQL Server 2016 Service Pack 1, the features this view reports – all of them except transparent data encryption – became available across editions rather than being limited to Enterprise and Developer. The SQL Server 2025 editions tables bear that out: table and index partitioning, data compression, columnstore and In-Memory OLTP are all Yes for Standard, and transparent data encryption is Yes for Standard too.

So a database blocked by 905 or 909 today is almost always being restored to an old build, or to Express. Express is where the real edition boundary now sits: it has no transparent data encryption, no change data capture and no resource governor, and its memory-optimised and columnstore allowances are 352 MB rather than 32 GB.

Full reference

What the view can return, and what each entry means

Which of those still constrains you

Read that table before reading the error message, because the error message pre-dates it. The realistic modern block is a restore onto Express, or onto a build old enough that the 2016 Service Pack 1 change had not happened.

Reading the block

Removing compression, carefully

SELECT OBJECT_NAME(p.object_id) AS ObjectName,
       p.index_id,
       p.data_compression_desc
FROM sys.partitions AS p
WHERE p.data_compression <> 0
ORDER BY ObjectName, p.index_id;

ALTER TABLE dbo.YourTable REBUILD WITH (DATA_COMPRESSION = NONE);
ALTER INDEX IX_YourIndex ON dbo.YourTable REBUILD WITH (DATA_COMPRESSION = NONE);

Permissions on the view

• Up to SQL Server 2019, sys.dm_db_persisted_sku_features requires VIEW DATABASE STATE on the database.
• From SQL Server 2022 it requires VIEW DATABASE PERFORMANCE STATE.
• Without the permission the view returns nothing rather than raising an error, so an empty result is not proof of anything.
• Run it as a member of sysadmin, or grant the permission explicitly, before you conclude a database is portable.

Establishing what the target can actually run

Those five answers, taken together, decide whether this is a five-minute patch, a rebuild of some indexes, or a purchase. Taking them in that order also stops the most expensive mistake, which is reading the error message text, seeing the word Enterprise, and buying on that basis alone.

Planning a move so this never happens at cutover

Run the view against every database while it is still on the source, and record the output alongside the target edition and build. That converts a failed cutover into a planning exercise, and it takes seconds per database. Where a row appears, check it against the target’s own editions table rather than against the error message text, because the message text names Enterprise for things Standard has run for several releases now.

Every code this article covers

Confirm the fix worked

1. The database comes online and state_desc in sys.databases reads ONLINE.
2. SELECT feature_name FROM sys.dm_db_persisted_sku_features; on the restored copy returns nothing the target edition cannot serve.
3. You ran that view as an account holding the permission it requires, so an empty result means something.
4. Application queries return against the tables you rebuilt, and row counts match the source.
5. DBCC CHECKDB completes cleanly on the restored database.

Questions people ask about this