The transition of customers to SAP S/4HANA represents more than a technical upgrade —it’s a transformation in how enterprise systems are extended, integrated, and future-proofed. At the heart of this shift is the Clean Core principle: minimizing modifications to the core ERP to maximize agility, maintainability, and upgradeability.
Clean Core is not just a best practice—it’s a technical debt reduction strategy that future-proofs the ERP landscape while promoting agility and resilience and is crucial for a fast adoption of AI based innovations.
As organizations adopt SAP Business Technology Platform (SAP BTP) to build side-by-side extensions, PostgreSQL on SAP BTP can be a suitable option in addition to SAP HANA or when it does not make sense to use the full HANA capabilities, for storing and managing data outside the core system.
Here’s why PostgreSQL on SAP BTP is not just a database option—but an important enabler for clean core success.
What is the Clean Core approach?
The Clean Core principle emphasizes a decoupled, modular architecture where:
- Custom logic should whenever possible built outside the SAP S/4HANA core.
- Core system upgrades are simplified due to reduced custom code.
- Extensions can leverage modern technologies via SAP BTP.
A decoupled model leans heavily on side-by-side extensibility: offloading custom applications, workflows, and data persistence to SAP BTP, while keeping the digital core stable and uncluttered.
PostgreSQL on SAP BTP: A 'natural' fit
PostgreSQL is an open-source, fully managed relational database available on SAP BTP, offering the reliability of enterprise SQL combined with the flexibility demanded by cloud-native applications. Here’s why it’s relevant in a Clean Core strategy:
1. Decoupled persistence for custom applications
With PostgreSQL, custom applications hosted on SAP BTP can maintain their own data persistence layer, avoiding unnecessary entanglement with the ERP core. This means:
- Instead of creating all custom tables within S/4HANA, developers can now manage many of them externally.
- Upgrade paths for the core ERP experience minimal disruption with less impact.
Developers have greater control over data structures and access patterns.
2. Open standards and developer productivity
PostgreSQL’s SQL compliance and broad integration support accelerate development.
- Use standard APIs together with CAP CDS for rapid prototyping and developing
- Integrate with CAP (Cloud Application Programming model) CDS Postgres database service
- Available on Kyma (Kubernetes-based runtime) on SAP BTP designed for building and running cloud-native microservices and serverless functions.
3. Cost-effective and scalable
As a managed offering, PostgreSQL on SAP BTP delivers:
- Lower total cost of ownership compared to other database options.
- Easily scalable to handle increasing workloads.
- High availability and backup support out-of-the-box.
- Available to be consumed via CPEA/BTPEA or as Pay-as-you-go.
- Free-Tier option available to support prototyping or development/testing scenarios.
4. Data governance and security
PostgreSQL on SAP BTP supports enterprise-grade compliance:
- Option of using only BTP private end-points for a more secure data access.
- Use the encryption capabilities provided by the underlying IaaS providers
- SSL is enabled by default and is enforced.
Clean Core in action: A Side-by-Side extension example
Scenario: Retail Chain Promotion Approval Workflow
Traditional (Non-Clean Core) approach:
A retail company wants to manage promotional discounts across stores with their own (non-standard) workflows and specific business requirements. In a non-clean core setup, custom logic for promotion creation, approval workflows, and validations (e.g., margin checks) will need to be added directly inside SAP S/4HANA, involving custom tables, workflows, and most likely UI changes.
Clean Core (Side-by-Side) approach:
With Clean Core principles, the retailer can build a promotion management app on SAP BTP, for example, using:
- CAP (Cloud Application Programming Model) for service logic
- PostgreSQL to store promotion drafts, approval history, metadata, and other relevant data
- SAP Fiori or SAP Build Apps for a user-friendly interface
Integration with S/4HANA via APIs to:
- Retrieve product and pricing data
- Push approved promotions to relevant systems (e.g., Pricing system, POS system, ...)
To sum up
- ☑️ S/4HANA remains clean — no custom tables or code inside the core
- ☑️ Retail process is decoupled — easy to evolve without touching ERP
- ☑️ PostgreSQL stores request and approval data — independently
Further readings:
Thanks for reading!
For more insights from the product team on PostgreSQL and Redis services on SAP BTP, explore:
Regards,
Antonio
Bluesky
