What a Preview Build Is For, and What It Is Not

A SQL Server preview lets you test features before the final release and provide useful feedback. It belongs in an isolated environment with replaceable data unless the exact program terms explicitly permit a different use.

Know Which Kind of Build You Have

Community Technology Previews and release candidates are stages in a release process. They aren’t synonyms for a supported production installation. A release candidate may approach final behavior, but its name doesn’t grant production rights or guarantee an upgrade path.

SELECT
    SERVERPROPERTY('ProductVersion') AS product_version,
    SERVERPROPERTY('ProductLevel') AS product_level,
    SERVERPROPERTY('Edition') AS edition,
    @@VERSION AS version_text;

Save the exact build with every test result. Preview behavior can change between builds, and a bug report without the build number leaves out essential context. Read the release notes and known issues for that specific build before testing a feature.

Check expiration and installation conditions in the supplied terms. Don’t assume a preview behaves like Developer Edition or an Evaluation installation you used before. Product names and license conditions describe different things and need separate attention.

Keep Real Operations Out of the Experiment

Use a separate instance or disposable environment with clear connection names. Keep production connection strings and credentials out of the test configuration. A preview application should not send real invoices, notifications, or payments merely because it was copied from a working project.

Use sample data or a protected, sanitized copy approved for testing. A preview doesn’t reduce the sensitivity of a customer backup. Restrict access and retain only the data required for the test. The environment can be temporary while its data exposure is permanent.

SELECT
    @@SERVERNAME AS connected_server,
    DB_NAME() AS connected_database,
    ORIGINAL_LOGIN() AS connected_login;

Run a connection identity check before destructive exercises. Confirm that names and permissions support the separation you intended. An instance called Preview isn’t isolated if another application quietly depends on it for daily work.

Choose a Small Question

Don’t begin by moving the entire application and hoping the new release feels better. Pick one feature relevant to your workload. Define the behavior you expect and the evidence that would confirm it. Keep the initial reproduction small enough for another person to run.

Record schema, data-generation steps, query text, and required configuration. If performance is the question, describe the workload shape and measure the output yourself. A preview announcement’s performance claim isn’t a result from your application.

Test failure behavior too. What happens with invalid input, cancellation, or a restarted service? A feature that works once in a clean session has answered only one question. Practical adoption depends on its behavior around the normal interruptions of an application.

Save Configuration With the Result

SELECT name, compatibility_level
FROM sys.databases
WHERE database_id = DB_ID();

SELECT name, value
FROM sys.database_scoped_configurations
ORDER BY name;

Feature availability can depend on compatibility level or a preview-specific setting. Record those conditions rather than assuming the default did everything. Include the driver and client versions where they matter. The same server build can appear different through clients with different capabilities.

Keep documented behavior separate from your observation. Write down the exact command and output, including errors. If a result differs from the documentation, that is useful feedback. Don’t silently rewrite the expected outcome until the test looks successful.

Read the Support and Upgrade Terms

General previews don’t automatically carry the support commitments of a released product. Some early-adopter programs provide specific support or go-live rights under their own conditions. Verify participation and terms rather than borrowing another organization’s permission.

Also verify whether the build supports upgrading to a later preview or the final release. The safe default is to expect rebuilding a disposable test environment. Keep scripts and source data outside that environment so the next build doesn’t require rescuing your only copy.

A database upgraded by a preview can have a format that an older released engine cannot restore. Preserve the original source backup before experimentation. Don’t make the preview instance the only place where business data or important development work exists.

Make Feedback Reproducible

Report the build, environment, expected behavior, actual behavior, and the smallest safe reproduction. Remove credentials and private data from the package. Include the conditions that make the issue disappear as well as those that trigger it. That helps distinguish a feature issue from a setup mismatch.

Retest on later builds and record whether the issue changed. When the final release arrives, repeat the relevant acceptance tests rather than promoting the preview result automatically. I use previews to reduce uncertainty ahead of adoption, not to create a hidden production dependency before release.

A preview is not an early production shortcut, it is a chance to test an assumption before committing to it.

This post was rewritten from scratch in September 2026. The original, published on 2011-09-06, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.