A namespace is registered once, globally unique, and permanent. It cannot be renamed, transferred to another prefix, or released back if you stop using it. Pick something short and boring that survives a rebrand, register it in an org you will never delete, and accept that every API name in the package carries it forever.
What you are actually registering
You register a namespace prefix in a Developer Edition org, then link that org to your Dev Hub so second-generation packaging can use it. The rules are narrow: up to fifteen characters, starting with a letter, letters, numbers and underscores only, no consecutive or trailing underscores. It has to be unique across every Salesforce customer, not just yours.
The Developer Edition org holding the registration becomes infrastructure. Losing access to it is a genuine problem, so record the credentials somewhere your organisation keeps things that outlive individuals.
What it prefixes
Everything in the package, in every reference to it:
SELECT acme__Amount__c, acme__Status__c
FROM acme__Invoice__c
WHERE acme__Status__c = 'Open'acme.InvoiceService svc = new acme.InvoiceService();Objects, fields, classes, labels, static resources, tabs, permission sets, custom metadata types, Visualforce pages. Apex uses a single dot, data components use a double underscore, and a custom field on a packaged object ends up with the prefix twice over in the full name.
The knock-on effects are where the cost lands. Every integration mapping carries the prefix. Every dynamic SOQL string building a field name has to include it. Describe calls return prefixed keys. Code written against an unprefixed org breaks inside the package, which is why you develop in a namespaced scratch org:
{
"namespace": "acme",
"packageDirectories": [{ "path": "force-app", "default": true }]
}The prefix also consumes characters in API names, so a long namespace and a long field name together can run into limits. Three to six characters is a sensible target.
How it affects limits
This is the part most teams do not know, and it is the strongest technical argument for a namespace on a distributed package.
Apex in a certified managed package, meaning one that passed security review, gets its own set of per-transaction governor limits rather than sharing the subscriber’s. Your queries and DML count against your namespace, so a subscriber trigger burning through the query limit cannot break your code. A cumulative ceiling applies across all namespaces in a transaction, around eleven times a single namespace’s allowance, so it is not unlimited. Still a substantial difference.
The same certification means the package’s custom objects, custom fields and Apex character count do not consume the subscriber org’s own allowances. For a subscriber near their object limit, that is the difference between being able to install your package and not.
Packaging without one
Unlocked packages can have no namespace, and for metadata you build for your own org that is usually right. The metadata looks native, there is no prefix in reports or integrations, and components can move between packages or into unpackaged source without renaming.
What you give up: nothing is protected from the org’s own customisation, two packages can collide on an API name, and none of the limit separation applies. The bigger issue is the exit. No route exists from unnamespaced metadata to a namespaced managed package that preserves API names, because the API names are exactly what would change. Every formula, report and integration referencing them changes too.
So the decision rule is about audience. Shipping to orgs you do not control, now or plausibly later: take a namespace on day one. Metadata for your own org only: skip it.
Choosing the actual string
Short, because it appears in every API name. Not the current product name, because products get renamed and the namespace will not. Not your company name if an acquisition is conceivable. Not a string that reads as an unfortunate word in another language. Check availability before getting attached to one: registration is immediate and final.
Frequently asked
Can I change a namespace later? No. Not by renaming, not by support request. The only route is a new namespace and a new package, with subscribers migrating data between them.
Can one namespace hold several packages? Yes, and that is a normal 2GP pattern. Several packages in one namespace can share code, and the @NamespaceAccessible annotation lets them reach members that are not global.
What if I register one and never ship? It stays registered to that org and cannot be reused by anyone, including you, for a different prefix. There is no cost, only the permanence.
Do I need a namespaced scratch org? For managed package development, yes. Prefix-related failures are invisible in an unnamespaced org and obvious in a namespaced one.
