How to handle different clients software (my own company software) versions deployment and who is the data owner and how to handle this?

Data Ownership and Storage:

You're correct that data ownership is typically defined through legal agreements. In SaaS models, even when data is stored in the provider's infrastructure, it commonly belongs to the customer, with the provider acting as a data processor. Offering data export and deletion capabilities is a standard practice and often a regulatory requirement.

Regarding storing data in client databases, yes, this is done in the industry through different deployment models:

• Provider-Hosted Model: Your company manages everything in your AWS account, including databases. This maximizes operational efficiency but requires you to handle all infrastructure management, security, scalability, and compliance.

• Customer-Hosted Data Plane: The application components that handle customer data run in the customer's environment (their AWS account or on-premises), while you maintain a control plane for management. This enables customers to maintain data sovereignty while benefiting from your expertise. You would manage application components in their environment while they manage the underlying infrastructure.

• Hybrid Approach: Allows deployment into customer environments while keeping control plane components in your account, accommodating diverse customer needs around data residency and compliance.

Handling Different Client Versions and Deployments:

For managing multiple clients with custom implementations, consider these multi-tenant partitioning approaches:

Silo Model (closest to your first option): Separate infrastructure (database instance/cluster) for each tenant. This provides full data isolation and control over resource usage but has higher infrastructure costs and slower onboarding for new tenants.

Bridge with Separate Databases: Each tenant gets a separate database within a shared infrastructure, offering data isolation with moderate onboarding agility and moderate infrastructure costs.

Bridge with Separate Schemas: Tenants share a database but have separate schemas, providing moderate isolation with faster onboarding and lower costs than full silos.

Pool Model (closest to your third option): Shared tables with tenant identification through IDs, offering the fastest onboarding and lowest infrastructure costs, but requiring careful design for data isolation and query performance.

Best Practices for Version Management:

When deploying different versions or customizations:

• Decouple schema changes from code changes to minimize risk during deployments
• Use additive schema modifications first (adding fields, entities) that are backward compatible
• Implement strong testing and QA phases before production deployments
• Consider deployment strategies like:
• Blue/green deployments to shift traffic between environments with minimal downtime
• Canary deployments to incrementally roll out changes
• Rolling updates to deploy gradually across instances

Recommendations:

Rather than maintaining separate branches per client (which creates significant maintenance overhead), consider:

1. Building a feature flag system within a common codebase to enable/disable functionality per tenant
2. Using configuration-driven customization where client-specific behaviors are defined through configuration rather than code branches
3. Implementing a plugin architecture for client-specific extensions
4. Choosing your isolation model based on:

• Customer requirements for data sovereignty and compliance
• Your operational capabilities and automation maturity
• Cost considerations and scale requirements
• The degree of customization needed per client

The industry trend is toward maximizing code reuse through configuration and feature management rather than maintaining separate codebases, while offering flexible deployment options (provider-hosted vs. customer-hosted) based on customer needs for data control and compliance.
Sources
Decision matrix - AWS Prescriptive Guidance
Best Practices for Managing Data Synchronization and Schema Changes - Blue/Green Deployments on AWS
Deployment strategies - Introduction to DevOps on AWS
SaaS deployment architectures with Amazon EKS | Containers