Sandbox vs. Developer Edition org: which one do you actually need?

August 4, 2026

Salesforce gives you two very different kinds of practice org, with confusingly overlapping names. Picking the right one is mostly about one question: do you need a copy of a real production org, or just a Salesforce of your own?

Developer Edition: a free org you own

A Developer Edition org is a standalone, free Salesforce org anyone can create in two minutes (developer.salesforce.com/signup). It's yours forever, it's connected to nothing, and it starts as a blank slate with sample data. Despite the small storage allowance (a few MB of data - fine for building, irrelevant for real records), it has nearly the full feature set turned on, including things some paid editions lack.

Best for: learning, prototyping, consultants without client access yet, building anything that isn't tied to an existing company org. The one caveat: log in occasionally - orgs left untouched for a very long time get flagged for deactivation (Salesforce emails you first).

Sandbox: a copy of your production org

A sandbox isn't standalone - it's a copy of a specific production org, created from that org (Setup → Sandboxes), and it requires a paid Salesforce edition that includes or purchases sandbox licenses. The copy carries your production's configuration: objects, fields, code, flows, profiles - your real world, minus (usually) the data.

Sandboxes come in sizes, and this is where the naming gets cruel:

Developer sandbox - the smallest tier: config only, small storage, refreshable daily. This is not a Developer Edition org. A "Developer sandbox" is a copy of your production; a "Developer Edition" is an unrelated free org. Two completely different things sharing a word.
Developer Pro - same idea, more storage.
Partial Copy - config plus a sample of real records, refreshable every few days.
Full - a complete clone, data and all; refreshable roughly monthly. For final staging and realistic testing.

Best for: anyone changing an org a business actually runs on. You build against the real configuration, and the path to production (change sets, Metadata API, DevOps tooling) is designed for exactly this.

Small practical tells you're in a sandbox: you log in at test.salesforce.com, and your username has the sandbox name appended (you@company.com.dev1).

The decision

You work in/for a company with a production org, and your changes are headed there → sandbox, no contest. It mirrors reality and deploys cleanly to it.
You're learning, experimenting, or building something standalone → Developer Edition. Free, instant, nobody's production at risk.
Both is normal. Plenty of developers prototype an idea in a personal Dev Edition, then rebuild it properly in the client's sandbox.

(One more term you'll meet eventually: scratch orgs - ephemeral, config-defined orgs from Salesforce DX that live days, not years. Powerful for source-driven teams; overkill while you're deciding between the two above.)

---

OrgTide treats both as equal workspaces - connect a sandbox or a Developer Edition org and the whole pipeline works the same, with production reachable only as a guarded deploy target. Getting started →