When searching for a cloud provider within European jurisdiction, T-Cloud Public (formerly Open Telekom Cloud / OTC) frequently makes the shortlist. It promises strict GDPR compliance, German data residency, and an enterprise feature set.

However, after running production-like analytics workloads on the platform, our hands-on experience revealed a mix of heavy financial overhead, architectural traps, and a reality check on the promise of "vendor-agnostic" open standards.

Here is what we learned after ingesting TPC-H data, evaluating DWS, and ultimately migrating our workload to STACKIT.

To stress-test T-Cloud Public's data capabilities, we ran a workload centered on the industry-standard TPC-H benchmark at scale factor 100 (a ~100 GB dataset). The objective was simple: ingest the data, run the standard suite of complex analytical queries, and evaluate cost efficiency.

That is where we hit the Data Warehouse Service (DWS) architectural trap.

In modern cloud analytics platforms (like Snowflake, BigQuery, or ClickHouse on S3), compute is separated from storage. You pay pennies to keep passive data in object storage and only trigger compute nodes when executing queries.

With T-Cloud Public's DWS (built on Huawei's GaussDB engine), compute and storage are tightly coupled inside the cluster nodes¹:

• The Setup: To ingest SF100 and run the full TPC-H query set at acceptable performance, we provisioned a 5-node cluster on dws.m3.xlarge instances.
• The Problem: You cannot store passive data inexpensively and spin up compute on demand for periodic queries. The nodes that hold the data are the nodes that run the queries.
• The Cost Impact: To keep the TPC-H dataset queryable at any given moment, the entire 5-node cluster had to remain active 24/7, regardless of whether a single query was running.
• The Bill: Keeping that cluster alive cost us nearly €2,000 per month, a massive outlay primarily spent keeping idle compute nodes awake just to host ~100 GB of stored data.

The kicker: for an intermittent analytics workload, the vast majority of that spend bought us nothing. We were paying enterprise compute rates around the clock to serve queries that ran for a fraction of the day.

When running workloads on enterprise cloud infrastructure, responsive support is critical, and this is where T-Cloud fell short. Even routine operational questions took far longer to resolve than we'd expect from an enterprise platform.

Our sample was limited: we never needed to escalate a production-stopping bug to Huawei's Level 3 backend engineering team. But the pattern on basic tickets was clear enough to worry us. If simple configuration questions sit in the queue, it raises a real question about how the platform would respond in an actual emergency. This concern is amplified by the split operating model, where T-Systems handles L1/L2 operations while relying on Huawei for the underlying software.

For a team betting production analytics on this platform, that response profile is a genuine risk, not a minor inconvenience.

T-Cloud Public heavily markets its use of standard OpenStack APIs as a major selling point, positioning it as a safeguard against vendor lock-in compared to AWS or Azure. And to be fair, this isn't just marketing gloss, T-Cloud Public's OpenStack fidelity is genuinely deep. Terraform providers, openstack CLI tooling, the standard OpenStack ecosystem works against it largely as-is.

In theory, that meant our infrastructure was vendor-agnostic and portable to any other OpenStack-compatible cloud. In practice, we couldn't actually cash in on that benefit.

Why? Because the European cloud ecosystem is shifting under OpenStack's feet. When we decided to leave T-Cloud Public and migrate to STACKIT (the cloud platform operated by the Schwarz Group), we ran straight into a structural wall: STACKIT has deprecated its OpenStack-compatible API, in favor of their own proprietary IaaS API².

As a result:

• Our "vendor-agnostic" OpenStack configurations could not be reused.
• We had to write entirely new, provider-specific configurations for STACKIT to rebuild our infrastructure.

Worth noting: this isn't a market-wide retreat from OpenStack; it's a split. OVHcloud, for instance, remains deeply committed to OpenStack; their Public Cloud is built directly on OpenStack across 8 regions, and they actively maintain and document standard OpenStack tooling as a first-class way to manage infrastructure. Hetzner sits on the opposite end for a different reason, as it was never built on OpenStack in the first place, running its own proprietary API from day one.

The real lesson here isn't that open standards don't work, but rather that portability is a two-sided contract. We held up our end by staying within standard OpenStack primitives instead of reaching for T-Cloud Public's proprietary extensions. But portability only pays off if the destination cloud honors the same standard at the moment you need to move, and the European market is currently split on whether it will.

The silver lining is this: we didn't lose all our portability gains, just the ones we'd staked on OpenStack specifically. Our Kubernetes workloads and manifests moved to STACKIT's managed cluster offering with minimal changes, and our object storage layer, built against the S3 API, was similarly indifferent to which provider was behind it. The difference is that K8s and S3 are contracts so widely adopted that providers support them regardless of what's running underneath. We can’t currently say the same thing about the OpenStack API.

So the practical takeaway isn't "avoid OpenStack" or "open standards failed us." It's: when you're designing for portability, bet on the abstraction layer with the broadest, most durable buy-in across providers, not the one that happens to be open-source. In our case, that meant Kubernetes and S3 earned their keep as portability layers, while OpenStack's API-level promise turned out to be only as durable as the least committed provider in the chain.

To be fair, our frustration stems largely from a mismatch between the platform and our specific workload. T-Cloud Public is a legitimate option under the right conditions:

• You need German data residency and strict GDPR compliance as a hard requirement, and want a Deutsche Telekom-operated platform to satisfy it.
• Your workloads run steady-state, 24/7 — where DWS's coupled compute/storage model is no longer a penalty, because the compute would be running anyway.
• You value staying on open OpenStack primitives to avoid proprietary PaaS lock-in within the platform, and either don't need cross-provider portability as an exit strategy, or have already confirmed your likely destination provider still supports OpenStack (OVHcloud, for instance, unlike STACKIT)..

Our problem was intermittent analytics on a platform priced for always-on compute — a poor fit that no amount of tuning would have fully fixed. For a different workload shape, the calculus changes.

1. Avoid coupled storage for intermittent analytics: If you don't require continuous 24/7 querying, DWS's coupled compute/storage model will burn through your budget hosting idle data.
2. Expect overhead in support: Even routine configuration and platform inquiries can suffer from sluggish response times, factor that into your risk assessment for production workloads.
3. OpenStack portability depends on your exit path, not just your entry point: Don't assume OpenStack compatibility guarantees a migration shortcut, the European market is split, with some providers (T-Cloud Public, OVHcloud) doubling down on OpenStack and others (STACKIT) actively replacing it with proprietary APIs. Before treating OpenStack as your portability strategy, confirm your likely destination is still committed to it. For a guarantee that doesn't depend on any single provider's roadmap, abstractions with broader buy-in (Kubernetes, the S3 API) are the safer bet.

¹Source: Huawei's own DWS product does offer a decoupled architecture elsewhere in its portfolio, but as of our testing, this option wasn't available on T-Cloud Public specifically."

²Source: https://docs.stackit.cloud/products/iaas-api/release-notes/#iaas-api-is-now-general-available-infrastructure-api-deprecation-begins