OPTUM SGS Healthcare Cloud — Additional Capability: DPaSS
Overview
DPaSS (Database Platform as a Service) is a centralized database platform that provides secure, scalable, and standardized database services for applications and clients across the enterprise. It enables organizations to provision, manage, and govern databases through a common platform while ensuring security, compliance, and operational efficiency.
Description
DPaSS provides a multi-tenant database platform designed to support multiple applications while maintaining strict client isolation. The platform leverages a One Client – One Database architecture model to ensure data segregation, improved security, simplified governance, and compliance with enterprise standards. It includes built-in capabilities for access management, monitoring, logging, disaster recovery, database version control, and data migration.
Architecture Diagram
We have three architecture models which can be presented in the case of DPaaS. All of them involve using a single database server and doing bifurcation at the database level.
One Client - One Database Model
This model states that each client will have one database of their own. This ensures maximum isolation between the clients. However, this will be a little resource intensive.
Many Clients - One Database with Different Schemas Model
This model states that one database will accommodate multiple clients, but they will have different schemas. For example, if a database contains a table for Users, then there will be n number of tables for n number of clients. The naming of the tables can be in the form of Users_MA or Users_AR where MA and AR are the clients. In this model, the client's isolation is less than the One Client - One Database model.
Many Clients - One Database with Same Schemas Model
This model states that one database will accommodate multiple clients, but they will have the same schemas. This means that there will be a single table which will have the data of all the clients. There will be an additional field for the client identifier on each table. This model provides the least isolation between the clients.
Model Comparison and Selection
The following table compares the three architecture models across key dimensions:
| Criteria | One Client – One DB | Many Clients – One DB (Different Schemas) | Many Clients – One DB (Same Schemas) |
|---|---|---|---|
| Isolation between clients | Maximum | Medium | Least |
| Secure PHI and PII data | Maximum | Medium | Least |
| Intensity of queries to filter client data | Least | Medium | Maximum |
The One Client – One Database model provides the highest isolation between clients and ensures maximum security of PHI and PII data. Since the databases are separate, proper RBAC setup prevents clients from accessing other clients' data — a key compliance requirement.
The Many Clients – One DB (same schemas) model results in highly intensive queries to fetch relevant client data, as all client data resides in shared tables, leading to large volumes of data in a single table.
The Many Clients – One DB (different schemas) model results in a vast number of tables within a single database, making it complex and difficult to manage at scale.
Therefore, the One Client – One Database model is the most suitable architecture for implementing DPaSS, given its alignment with compliance requirements, data isolation needs, PHI/PII security standards, and query efficiency.
Supported DPaSS Features
- Logging
- RBAC (Role-Based Access Control)
- Disaster Recovery
- Data Migration
- Liquibase
DPaSS Features
- Centralized database platform for multiple applications and clients.
- Dedicated database per client to ensure maximum tenant isolation.
- Role-Based Access Control (RBAC) for granular database access management.
- Centralized logging and auditing for operational visibility and compliance.
- Monitoring and alerting for database and server health.
- Disaster Recovery (DR) and backup capabilities to support business continuity.
- Secure database access through Virtual Network (VNet) integration.
- Microsoft Entra ID integration for identity and access management.
- Database version control and schema management using Liquibase.
- Data migration framework to support onboarding and migration of existing databases.
- Standardized client onboarding process for rapid provisioning and governance.
Scope
The scope of DPaSS is to provide a secure, centralized, and governed database platform for enterprise applications while ensuring client data isolation, security, monitoring, compliance, backup, recovery, and streamlined onboarding capabilities.
DPaSS Features — Detailed
1. Logging
The Logging capability within DPaSS provides centralized monitoring, auditing, and operational visibility across SQL Managed Instance and MySQL platforms. By integrating with Azure Log Analytics Workspace, it enables the collection, storage, and analysis of database and server logs, including audit logs, diagnostic logs, connection logs, security audit events, performance metrics, error logs, slow query logs, and DML activity logs. The capability supports server-level and database-level monitoring, user connection and authentication tracking, performance diagnostics, and centralized troubleshooting. For SQL Managed Instance, it provides comprehensive auditing and centralized audit log storage, while for MySQL it supports audit logging, query visibility, connection monitoring, DML tracking, slow query analysis, error logging, and downloadable server logs for investigations. This helps provide enhanced operational visibility, security monitoring, compliance auditing, incident investigation, performance analysis, and a complete audit trail of database activities.
2. RBAC
The RBAC capability within DPaSS provides a standardized access management framework across SQL Server, SQL Managed Instance, and MySQL environments. It leverages Microsoft Entra ID and Secure group integration to manage database access for users, service principals, and managed identities. Access is controlled through fixed and custom database roles, enabling permissions to be assigned at the database, table, view, and stored procedure level. Users are onboarded through Secure, mapped to Entra ID groups, and automatically inherit database permissions based on approved group memberships. The capability supports secure authentication, role-based access assignment, and granular access control for both human and non-human identities. DPaSS also automates RBAC deployment using Liquibase and GitHub Actions, providing version-controlled user creation, role provisioning, permission management, rollback support, and standardized deployments across development, non-production, and production environments. This approach helps enforce least-privilege access, maintain tenant isolation, support compliance requirements, streamline onboarding and access management, and provide a consistent access control model across supported database platforms.
3. Disaster Recovery
The Disaster Recovery capability within DPaSS provides recovery strategies for SQL Server, SQL Managed Instance, and Azure Database for MySQL to help protect database workloads from outages, regional failures, and data loss events. Depending on platform and business requirements, the capability supports cross-region replication, automatic and manual failover, backup-based recovery, and replica-based recovery options with varying Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO). For SQL Server, supported options include Failover Groups, Active Geo-Replication, Geo Restore, and Standby Replicas. For SQL Managed Instance, Failover Groups provide automatic cross-region failover using asynchronous replication between primary and secondary managed instances, while requiring synchronization of server-level objects and matching infrastructure configurations. For Azure Database for MySQL, disaster recovery options include Zone Redundant High Availability for automatic failover within a region, Geo-Restore using geo-redundant backups in paired regions, and Read Replicas that support recovery through manual promotion. Together, these capabilities provide business continuity through database recovery, failover, and replication mechanisms across supported database platforms.
Zone-Redundant High-Availability (HA) Architecture
This architecture depicts Zone Redundant High Availability for Azure Database for MySQL Flexible Server. Application traffic is directed to a primary MySQL server hosted in Availability Zone 1, while data and transaction logs are synchronously replicated to a standby server in Availability Zone 2. If the primary zone becomes unavailable, the standby server automatically takes over, allowing applications to continue using the same endpoint. In addition, backups are stored in zone-redundant storage to provide additional protection and recovery capabilities.
4. Data Migration
The Data Migration capability within DPaSS provides migration strategies for moving on-premises SQL Server and MySQL workloads to Azure SQL Database, Azure SQL Managed Instance, and Azure Database for MySQL Flexible Server. The capability supports multiple migration approaches, including offline, online, replication-based, backup and restore, and continuous synchronization strategies, allowing migrations to be aligned with application requirements, downtime tolerance, and target platform characteristics. For Azure SQL Database, supported approaches include BACPAC Export/Import, Azure Database Migration Service (DMS) offline migrations, Azure DMS online migrations using continuous synchronization, and Transactional Replication. For Azure SQL Managed Instance, migration options include Backup and Restore to Azure Blob Storage, Log Replay Service (LRS), Managed Instance Link (MI Link) for near real-time synchronization, and DMS-assisted migrations that provide governance, reporting, and centralized tracking. For Azure Database for MySQL Flexible Server, supported approaches include Logical Dump and Load, Azure DMS online migrations using binlog-based synchronization, and Native Replication. These strategies enable organizations to choose between planned outage migrations, low-downtime migrations, and near-continuous synchronization approaches while supporting database-scoped, instance-level, cross-database, and MySQL-specific migration requirements.
5. Liquibase
Liquibase is the database change management capability within DPaSS that provides version-controlled, automated, and repeatable database deployments across development, non-production, and production environments. It uses changelogs and changesets to manage database schema and data changes, supports automated SQL generation and execution, and enables controlled updates and rollbacks through commands such as update, updateSQL, rollback, and rollbackSQL. Integrated with GitHub Actions and CI/CD pipelines, Liquibase supports automated deployments to Azure Kubernetes Service (AKS), tracks and audits database changes, and provides a standardized approach for managing schema evolution and versioned database releases. The implementation includes structured repositories for changelogs, changesets, release files, and database objects, while supporting validated database operations such as table creation, data insertion, updates, deletions, schema modifications, SQL generation, and rollback execution.
Architecture Overview
- Main changelog file acts as the entry point for database deployments.
- Version-specific changelog files contain release-level database changes.
- Changesets define individual database operations.
- Liquibase generates SQL statements from changelog definitions.
- Generated SQL is executed against the target database.
- Successful execution proceeds to subsequent changesets.
- Failures stop execution and prevent further updates.
