In recent conversations with architects and practitioners, one question comes up repeatedly “If SAP Datasphere already gives me a HANA Cloud Database instance, why do many industries still create new standalone HANA Cloud instances?” Mindset has seen clients with a SAP Datasphere instance and multiple instances of SAP HANA Cloud Database for CAP applications or other purposes. They can utilise their existing landscape, and there is no need to create a separate PostgreSQL or standalone HANA Database.
This blog, mentions how the HDI container can be created on the SAP Datasphere Instance and used by the CAP Application. Additionally the Mindset Team is available if you have a complex landscape and want to optimise it.
If an organization has multiple HANA Datasphere instances, the answer lies in control, flexibility, and cost strategy. Let’s break it down.
Reasons Why Industries Often Avoid the Built-in Datasphere HANA DB
Although Datasphere comes with its own HANA Cloud Database, industries frequently create separate HANA Cloud instances and containers. Common reasons include:
- Separation of Concerns – Keeps analytical workloads separate from system-of-record data.
- Scalability & Performance – Standalone instances allow custom memory/storage sizing without impacting Datasphere.
- Security & Governance – Easier to enforce data isolation, access control, and compliance rules.
- Cost Optimisation – Reduces load on Datasphere licensing by offloading heavy transformations to a separate instance.
Reasons Why You Should Consider Using the Datasphere HANA DB
At the same time, the built-in Datasphere DB comes with its own strengths, which many organisations underutilise:
- Tight Integration – Pre-connected with Datasphere, ready to use with no extra setup.
- Lower TCO – Included in your subscription; avoids additional licensing.
- Simplified Landscape – Fewer systems to manage, reducing IT overhead.
- Lightweight Extensions – Great for harmonization, staging, or transformations.
- Aligned Security – Uses SAP’s standard governance and compliance framework.
- Faster Innovation – Ideal for quick POCs, pilot analytics, or departmental projects.
Rule of Thumb: Use the Datasphere DB for agility, simplicity, cost control; use a standalone HANA instance for enterprise-grade scalability and hybrid integration.
Cost Implications: Existing vs. New HANA Cloud Instance
The key trade-off usually comes down to cost.
- Using Datasphere HANA DB → Included in your Datasphere subscription (no extra infra cost). Limited in size and flexibility.
- Creating New HANA Cloud Instance → Extra license + pay-per-resource (memory, storage, compute). Comes with provisioning, monitoring, and sometimes replication costs.
Real-world Architecture Decision CAP application with PostgreSQL or SAP Datasphere HANA Cloud Instance:
CAP and PostgreSQL are common because it is open-source, cost-effective and flexible for transactional workloads.
SAP HANA Datasphere HANA Cloud DB is embedded with every Datasphere tenant, optimised for analytics, semantic modelling and Integration.
It depends on the type of use case, depending on different things like Analytical Use, Governance & Security, Cost Control, Cloud Flexibility and Full DB Admin Control.
Important Points to Consider:
- Don’t overlook the built-in Datasphere DB — it’s a hidden gem for quick innovation and cost savings.
- Use standalone HANA Cloud when you need enterprise-level performance, scaling, and hybrid integrations.
- Size smartly: Prod should be High Availability; Dev/Test can be lean and even paused to save costs.
The decision isn’t about which is better, but about matching the right tool to the right use case.
