---
title: Understanding Services and Scaling | Shopware Community Hub
description: >-
Learn how MySQL, S3, OpenSearch, controlled service access, and scaling on
Native PaaS fit together so that service access and infrastructure
expectations…
canonical_url: 'https://hub.shopware.com/learn/unit/understanding-services-and-scaling'
---
# Understanding Services and Scaling
- Explain how service isolation works per application on Native PaaS.
- Relate service isolation to debugging, data safety, and staging workflows.
- Use controlled service access such as a MySQL tunnel when application-level debugging is not enough.
- Describe scaling on Native PaaS as planned operations rather than fully automatic AWS-style elasticity.
# Understanding Services and Scaling
After debugging and log inspection, the next question is different: what is isolated per application, how do you access these services safely, and what should you expect from scaling?
Native PaaS is not a self-managed AWS account where every runtime detail is under your direct control.
Some services are clearly isolated per application, some operational access goes through managed platform helpers, and some scaling changes need coordination with Shopware.
In this learning unit, you learn how to read that service model more clearly so that debugging, database access, caching discussions, and scaling expectations start from the right assumptions.
## Understand Per-Application Isolation
The first important rule is that applications are isolated at the data and service layer. One application should not behave like a noisy neighbor to another.
In practice, this isolation shows up most clearly in the services attached to each application:
- **MySQL**: One database per application
- **S3**: Public and private buckets per application
- **OpenSearch**: A shared cluster with dedicated indices per application. Each application can access only its own indices.
Some shared resources can still exist at the organization level, for example, buckets for shared assets such as logos. That does not change the main rule: Application runtime data stays separated.
That way, debugging, data safety, and staging refresh all start from the right assumption.
In the current environment, copying a database between applications in the same project is described as a normal workflow for staging scenarios rather than as a custom migration exercise.
## Access Services Safely
Once you understand that services are isolated per application, the next question is how you access them.
### MySQL Tunnel
Use the service tunnel when application-level debugging is not enough, and you need controlled access to the database layer itself.
```bash
sw-paas open service --service database --port 3306
```
This is useful for debugging migrations, checking database state, or doing careful read-only inspection from a local client.
It should not turn into routine production editing. Use local GUI clients only with least-privilege accounts and proper change management. Production writes through tunnels are high risk.
The rule of thumb is simple: Use tunnels for controlled inspection and debugging, not as a substitute for normal production operations.
## Treat Scaling as Planned Operations
The next common misunderstanding is scaling. Native PaaS is managed and scalable, but not every scaling expectation should be framed like raw AWS autoscaling.
Use this mental model:
- Services such as database and app nodes can often be scaled per application.
- Staging and production do not need the same sizing.
- Large traffic spikes still require planning and coordination with Shopware.
That also means you should not assume a fully automatic scale-to-load model without human input.
Current behavior is described more as managed scaling with operational planning than as unlimited self-adjusting elasticity.
In practice, this has a few consequences:
- Container size limits still exist.
- Very large PHP memory requirements may still need application optimization or a tier change.
- The current scaling model is described mainly in terms of **Horizontal Scaling (HPA)**.
The key takeaway is simple: Scaling is real, but peak-event readiness is still something you plan for, not something you assume away.
## Keep the Infrastructure Context in Mind
Behind the managed runtime, enablement materials refer to services such as **RDS** for MySQL, **S3**, **Valkey**, **OpenSearch**, multi-AZ high availability, and backups with point-in-time recovery posture.
You do not need to operate those components like raw cloud services in this course.
The important expectation is this: Native PaaS gives you managed infrastructure services, not arbitrary infrastructure freedom.
That means two things:
- You can reason about the platform as a managed infrastructure on top of known building blocks.
- But you should not assume full cloud-level control or make contractual promises based only on technical positioning language.
For formal uptime, recovery guarantees, or exact RPO/RTO, always confirm the current contractual position with Shopware instead of relying on technical descriptions alone.
## Check your understanding
Use these questions to check the two core ideas from this learning unit: application services are isolated, and scaling on Native PaaS should be treated as planned operations rather than assumed AWS-style automation.
A migration behaved differently on staging than expected, and the team needs to inspect the database state. What is the safest first access pattern?
Use a controlled database service tunnel for careful inspection, preferably read-only and with proper change management
Open a shell on a running pod and make production data fixes directly from the application container
Export the shared global database because all Native PaaS applications use the same schema by default
A merchant expects a major campaign to create several times the usual traffic next week. How should you frame scaling on Native PaaS?
Assume the platform will scale infinitely and automatically without planning
Plan capacity with Shopware, because managed scaling exists but large changes may still need advance coordination
Disable managed services before the campaign so the application has fewer dependencies
## Summary
In this learning unit, you learned:
- Application services are isolated, especially at the data layer.
- Service tunnels are for controlled access, not routine production editing.
- Scaling is real, but peak scaling still needs planning and coordination.
With this understanding, you can reason more clearly about service isolation, access the right layer more safely, and set more realistic expectations for managed services and scaling on Native PaaS.