SQL Server comes in several editions suited to different use cases and budgets. For development, SQL Server Developer Edition is free and identical to Enterprise Edition — every feature available, with the restriction that it cannot be used in production. LocalDB is even simpler for local development: it runs on demand (no Windows Service required), each developer gets their own automatic instance, and it integrates directly with Visual Studio. Understanding which edition to use where prevents the common mistake of developing against LocalDB but deploying to Standard/Enterprise where configuration differences cause surprises.
Edition Comparison
-- ── Check your SQL Server version and edition ─────────────────────────────
SELECT
@@VERSION AS FullVersion,
SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('ProductLevel') AS ServicePack,
SERVERPROPERTY('ProductVersion') AS Version,
SERVERPROPERTY('EngineEdition') AS EngineEdition;
-- EngineEdition: 1=Personal, 2=Standard, 3=Enterprise, 4=Express, 5=SQL Azure, 8=Managed Instance
-- ── LocalDB — automatic instance management ───────────────────────────────
-- Start LocalDB instance (usually auto-starts when first connection is made):
-- sqllocaldb start MSSQLLocalDB
-- sqllocaldb info (list all instances)
-- sqllocaldb create "MyInstance" (create a named instance)
-- sqllocaldb delete "MyInstance" (delete an instance)
-- ── List SQL Server instances on the machine ──────────────────────────────
-- sqllocaldb info (LocalDB instances)
-- sqlcmd -L (network SQL Server instances)Server=(localdb)\MSSQLLocalDB — the backslash before the instance name and the specific instance name MSSQLLocalDB (the default automatic instance). Entity Framework Core migrations and dotnet ef database update work seamlessly with this connection string. When you graduate from LocalDB to a full SQL Server Developer or Express instance, only the Server= part of the connection string changes — everything else stays identical.Edition Selection Guide
| Edition | Cost | Max DB Size | Best For |
|---|---|---|---|
| LocalDB | Free | 10 GB | Local development, unit tests |
| Express | Free | 10 GB | Small production apps, shared dev |
| Developer | Free (no production use) | Unlimited | Full-featured development and testing |
| Standard | Paid | Unlimited | Mid-size production workloads |
| Enterprise | Paid | Unlimited | Large production, advanced HA/DR |
| Azure SQL Database | Per DTU/vCore | Up to 4 TB | Cloud-hosted production, PaaS |
Common Mistakes
Mistake 1 — Using LocalDB in a shared development environment (one developer’s changes affect others)
❌ Wrong — team shares a LocalDB instance; migrations from one developer break another’s local development.
✅ Correct — each developer has their own independent LocalDB or Docker SQL Server container; shared dev/test environments use a dedicated SQL Server Developer instance.
Mistake 2 — Forgetting that LocalDB does not support SQL Server Agent (scheduled jobs fail silently)
❌ Wrong — developing with Hangfire SQL Server storage against LocalDB; SQL Server Agent is unavailable; Hangfire falls back to polling.
✅ Correct — for features requiring SQL Server Agent or full SQL Server services, install Developer Edition.