Database.com
Database.com was Salesforce's standalone cloud database service, sold as a multitenant relational database that developers could use without buying the full CRM application layer. It exposed the sa…
Definition
Database.com was Salesforce's standalone cloud database service, sold as a multitenant relational database that developers could use without buying the full CRM application layer. It exposed the same data engine that powered Salesforce, including custom objects, custom fields, SOQL, SOSL, and Apex, but it left out the Sales Cloud and Service Cloud features built on top. The idea was to give developers a database-as-a-service they could call from Java, .NET, Ruby, PHP, or any language that speaks REST and SOAP.
Database.com is retired. Salesforce stopped selling it as a separate product and folded the same capability into its Platform license tiers and the wider Customer 360 lineup. If you see Database.com mentioned in older articles or documentation, treat it as historical context. The official Lightning Platform Fundamentals page that once covered its database concepts now shows a Document Retired notice, and new projects should target a standard Salesforce org instead.
From standalone database to a feature of the Platform
What Database.com actually was
Database.com packaged the Salesforce data layer as a product you could buy on its own. You got the multitenant relational database, the metadata-driven object model, and the security and identity controls that come with it. Developers created custom objects and custom fields, then read and wrote records through the SOAP API and the REST API. The query languages were SOQL and SOSL, the same ones used across Salesforce, and server-side logic ran in Apex. What you did not get was the application layer. There were no page layouts, no Visualforce pages, no reports or dashboards, and no Sales or Service Cloud objects waiting for you. The pitch was simple. If you were building a mobile or web app in some other stack and just needed a trusted cloud database with a real permissions model, Database.com gave you that without the cost or clutter of a full CRM. It ran on the same infrastructure as Salesforce, so the data engine was battle tested rather than something new and unproven.
Why it sat next to Force.com
Database.com and Force.com were close cousins, and the difference is worth pinning down. Force.com was the platform-as-a-service offering, with the full toolkit for building apps that ran inside Salesforce. That meant page layouts, Visualforce, workflow, reports, and dashboards on top of the database. Database.com deliberately removed those pieces and exposed only the data tier through APIs. You brought your own front end and your own compute, and Salesforce stored and served the records. This made it attractive for teams who had already committed to a language or framework like .NET or Ruby and did not want to learn Visualforce or move their whole application onto Salesforce. The trade was real. You lost the rapid app-building tools that made Force.com productive, and in return you got a clean database service you could call from anywhere. Over time Salesforce decided that maintaining a separate stripped-down product was not worth it, since the same outcome could be reached by licensing the platform at a lower tier. That decision is what eventually led to the retirement.
The APIs and query languages it used
Because Database.com had no user interface of its own, the API was the product. Developers talked to it through the SOAP API and the REST API, sending and retrieving records over standard web service calls rather than raw SQL. Querying used SOQL, the Salesforce Object Query Language, which looks like a SQL SELECT but is scoped to the object model and its relationships. Full-text style searching used SOSL. For logic that needed to run on the server, such as triggers and stored procedure style routines, the language was Apex. This is the same API and language surface that a modern Salesforce org exposes today, which is part of why the standalone product became redundant. Anyone who learned to call Salesforce from an external app already had everything Database.com offered. The key thing to remember is that you never wrote SQL against it. Records were objects, relationships were defined by fields, and access was governed by the same sharing and permission model that protects Salesforce data. That security posture, not raw speed, was the selling point for mobile and social apps that needed identity and access management baked in.
Why Salesforce retired it
Salesforce retired Database.com because the standalone use case stopped justifying a standalone product. The company moved toward a unified platform story, where the database, the runtime, and the developer tools all live in one place rather than being sold as separate slices. The official documentation that once described Database.com database concepts, inside Lightning Platform Fundamentals, now returns a Document Retired notice, which is the clearest signal that the product is no longer part of the active lineup. Customers who only needed a cloud database with custom objects could get that by licensing a Platform tier on a regular org. Customers who needed off-platform compute had Heroku, which Salesforce had acquired and positioned for exactly that. With both gaps covered by other offerings, keeping a third product that did less than either one made little sense. The retirement was not a dramatic shutdown event so much as a quiet consolidation. The capability did not disappear, it just moved into the products that surrounded it, which is why most developers never had to scramble to replace anything.
What replaced it today
If you want what Database.com promised, you reach for a standard Salesforce org with a Platform license. The Salesforce Platform and Lightning Platform license tiers give you the database, custom objects, custom fields, Apex, and the SOAP and REST APIs, without paying for Sales Cloud or Service Cloud features you will not use. A user on a Platform license can work with custom objects and a handful of standard objects like Accounts and Contacts, which covers most build-your-own-app scenarios. For workloads that need compute outside the Salesforce data model, Heroku runs your application code and can connect back to Salesforce data through Heroku Connect or the APIs. The broader Customer 360 portfolio ties these together, and Data Cloud now handles the large-scale data engine role for analytics and unification. The practical advice is short. Do not architect anything new around Database.com. Stand up a Developer Edition or a Platform-licensed org, model your data as custom objects, and call it from your external app using REST. You end up with the same trusted multitenant database, plus a path to the rest of the platform if your needs grow.
How to read old Database.com references
You will still bump into Database.com in blog posts, training material, and forum threads from the early-to-mid 2010s. Knowing how to read them saves time. When an old article talks about creating custom objects and querying with SOQL on Database.com, that part still applies almost word for word to a modern org, because the object model and query language carried forward. What does not carry forward is anything about buying or provisioning Database.com as a separate service, its pricing, or its standalone signup flow. Those steps are gone. If a tutorial tells you to log in at a Database.com endpoint or points you to a Database.com-specific developer console, stop and translate it to the equivalent action in a normal Salesforce org. The same is true for any documentation link that lands on a Document Retired page. Treat the concepts as durable and the product mechanics as obsolete. For interviews and certifications, knowing that Database.com existed and why it was retired is enough. You are unlikely to be asked to use it, but you may be asked to explain how Salesforce evolved its platform strategy, and Database.com is a clean example of that consolidation.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Database.com.
Hands-on resources to go deeper on Database.com.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What was Database.com when Salesforce offered it as a product?
Q2. Which modern offering covers the Database.com use case of building on Salesforce storage without Sales or Service Cloud?
Q3. Should a team start a brand-new project on Database.com today?
Discussion
Loading discussion…