SQL Server 2025 Developer Edition Review: Free, Full-Featured, Limited

Fix it now

SQL Server 2025 ships two Developer editions, not one. Enterprise Developer carries all the functionality of Enterprise, and Standard Developer matches Standard. Both are licensed for development and test rather than production. Choosing the one that matches the edition you will actually buy removes the oldest trap in this product.

1. Use Standard Developer if you intend to licence Standard in production. Developing against the ceilings you will actually run under is the whole point, and this option did not exist in earlier releases.
2. Use Enterprise Developer if you genuinely intend to licence Enterprise, or if you are evaluating Enterprise-only capability before deciding.
3. Use either for developer machines, shared development and test servers, build agents running integration tests, training and proof of concept work.
4. Skip it for anything the business relies on, including reporting copies, warm standby servers and user acceptance environments people work in for real. Those are production use whatever the server is called.
5. Skip it as a way to avoid licensing a small production database. SQL Server Express is the free edition that is licensed for production, within its published limits.
6. Before you choose a production edition, run the persisted features check on every database and then load test against the actual Standard ceilings.

The test that works is simple. If the instance stopped this afternoon, would somebody outside the development team be unable to do their job? If yes, it is production and it needs a production licence.

If that settles it you can stop here. If you want the edition limits, the checks to run and the route to production, keep reading.

Why it happens

Developer edition is the full engine, free, with one condition attached: it may not be used in production. That is a generous arrangement and it is also the source of most of the trouble people have with it, because the line between development and production is drawn by what a system is used for rather than by what it is called. Microsoft’s description is that Developer editions include the functionality of the corresponding edition but are licensed for use as a development and test system, not as a production server.

The change worth knowing about in SQL Server 2025 is that there are two of them. Enterprise Developer matches Enterprise and Standard Developer matches Standard. That directly addresses the classic failure in this product, where a team builds happily against Enterprise features their eventual production licence will not include and only discovers it during deployment. If you already know you are buying Standard, develop on Standard Developer and the mismatch cannot happen.

The edition ceilings are where the real risk now sits, and they have moved. SQL Server 2025 Standard is limited to the lesser of 4 sockets or 32 cores for the database engine, with 256 GB of buffer pool memory per instance, and 32 GB each for the columnstore segment cache and memory-optimised data. Those are larger than the SQL Server 2022 figures, so if you sized a design against an older article you have more headroom than you think. Express is limited to the lesser of 1 socket or 4 cores, 1,410 MB of buffer pool memory, and a maximum relational database size of 50 GB.

That Express figure is worth a second look, because it is the number most likely to be stale in whatever you read before this. A 50 GB per-database ceiling makes Express a legitimate answer for a much larger class of small production application than it used to be, and Express is licensed for production. If your reason for reaching for Developer edition was that Express was too small, price the current limits before you assume that is still true.

The persisted features check is still worth running and its value should be stated accurately. The dynamic management view sys.dm_db_persisted_sku_features lists edition-specific features enabled in the current database, and a database containing them cannot be moved to an edition that does not support them. What has changed is that since SQL Server 2016 Service Pack 1, everything that view reports except transparent data encryption is available across multiple editions. In practice the check now returns very little, which means an empty result is much weaker reassurance than it used to be. The realistic blocker on a move from Enterprise Developer to Standard is the scale ceiling, not the feature list.

So the honest sequence is: run the check, then test against the ceiling. Configure an instance to the memory and core limits of the edition you intend to buy and run a realistic load against it before signing anything. That is the step that catches the problems, and it is the step most teams skip because the feature check came back empty and felt like a clean bill of health.

Full reference

What non-production means in practice

A Developer edition instance used as a disaster recovery target is both a licensing breach and an operational trap, because the moment you fail over to it you are running production on an unlicensed instance during the worst week of your year. Passive failover rights come with a properly licensed server, and that is the arrangement to build.

The SQL Server 2025 edition ceilings

Enterprise Developer inherits the Enterprise column and Standard Developer inherits the Standard column, which is what makes the choice between them a design decision rather than a formality. Develop on the one whose ceilings you will be running under.

Checking a database before you choose an edition

SELECT feature_name
FROM sys.dm_db_persisted_sku_features;

• An empty result means nothing edition-specific is persisted in that database.
• Names in the result are features your production edition must support before the database can be restored or attached there.
• Since SQL Server 2016 Service Pack 1, everything this view reports except transparent data encryption is available across multiple editions, so an empty result is weak reassurance rather than a clean bill of health.
• The check has a further blind spot: it only reports what is stored in the database. Runtime behaviour that Standard limits, including the memory and core ceilings above, will not appear.
• Catch those by configuring a test instance to the ceilings of the edition you intend to buy and running a realistic load against it.

Going live

There are two routes and both are ordinary. An edition upgrade through SQL Server setup converts the existing instance in place, keeping databases, logins and jobs, so connection strings do not change if the instance name stays the same. A backup and restore onto a newly built licensed instance is often tidier, because it lets you leave a development-shaped configuration behind and gives you a tested restore as a side effect. Either way the instance stops while it happens, so plan the window.

The licensing decision at that point is per core against Server plus CAL. Microsoft licenses Enterprise per core only, while Standard can be licensed either way. Per core suits databases reached by customers, by the public, or by an unknown number of users. Server plus CAL suits a known, countable user population and often costs a good deal less for an internal application with a modest headcount. Count the humans and the devices before deciding, because the wrong choice here follows the server for its whole life.

Developer edition can sit on the same host as a licensed production instance without additional licensing cost, provided it is a separate instance and nothing production actually uses it. That is a normal arrangement on a well-specified server, and it is worth documenting so the next administrator does not assume otherwise.

Three habits that keep this clean

1. Keep an explicit list of which instances run a Developer edition, which flavour, and what each one is for. Review it when people join and leave.
2. Run the persisted features check on every database before choosing a production edition, and then load test against the ceilings of that edition.
3. Never let a Developer instance drift into a role the business depends on. That drift is gradual, undocumented, and discovered by an auditor rather than by you.

Questions people ask about this