Alternativa apenas UE a Oracle Cloud (OCI).

Oracle Cloud Infrastructure is the smallest of the major hyperscalers in EU mid-market but punches above its weight in regulated industries because of the Oracle Database lock-in. Oracle Corporation is a US company; OCI EU regions (Frankfurt, Amsterdam, Marseille, Milan, Madrid, Stockholm, Zurich) are EU-located but US-controlled under the CLOUD Act. Oracle has marketed "EU Sovereign Cloud" since 2023 - operationally separated EU regions with EU-resident staff - but the parent jurisdiction is unchanged. For Schrems II-strict analyses, that is not full sovereignty.

United States Stack de substituição, apenas UE 12 serviços mapeados
Fornecedor
Oracle Cloud (OCI)
Sede
Austin, TX
Jurisdição
United States
Regime jurídico
CLOUD Act, FISA 702, EO 12333

"Região UE" não é soberania. Quatro perguntas decidem.

A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.

Residência

Onde os dados estão fisicamente armazenados?

Não "na cloud": que centro de dados, em que país, sob que jurisdição.

Subprocessadores

Quem mais está no seu caminho de dados?

Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.

Jurisdição

Quais leis podem forçar a divulgação?

Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.

Custódia de chaves

Quem detém realmente as chaves de cifragem?

Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.

Não cumpre AWS · Azure · GCP · Região da UE

Falha em jurisdição e custódia de chaves.

Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.

Cumpre Stack gerida pela Binadit

Passa nos quatro.

Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.

Porque é que as equipas estão a sair Oracle Cloud (OCI)

Oracle exits we have run almost always involve a database migration in addition to infrastructure - typically Oracle DB → PostgreSQL, which is a substantial project on its own. The triggers: a financial services audit under DORA flagging Oracle as a US-jurisdictional concentration risk, a cost review that uncovered the true Oracle DB licensing exposure on cloud, or a strategic decision to remove the Oracle dependency entirely. The mid-term saving is dramatic when both the OCI infrastructure cost and the Oracle DB licence cost are eliminated.

Oracle Cloud (OCI) serviços e os seus equivalentes apenas na UE

Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Oracle Cloud (OCI) com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Compute Instances

O que usamos no lugar
Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.
Nota de engenharia
Migração de VM padrão; reconstrução e rebase da imagem. O Oracle Linux pode ser substituído por Rocky ou Alma sem impacto na aplicação.

Object Storage

O que usamos no lugar
Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
Nota de engenharia
O OCI Object Storage tem uma API não compatível com S3; a reescrita é pequena, mas requer alterações no SDK.

Autonomous Database

O que usamos no lugar
Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.
Nota de engenharia
A tarefa de migração individual mais longa. Ferramentas como o ora2pg e o migrator da Cybertec melhoraram significativamente. Planeie uma execução paralela de 3 a 9 meses, dependendo da complexidade do schema.

OKE (Oracle Kubernetes Engine)

O que usamos no lugar
Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.
Nota de engenharia
Os Helm charts e YAML transferem-se sem problemas; funcionalidades específicas do OKE (nodepools managed do Container Engine for Kubernetes) são substituídas por equivalentes standard.

Block Volumes

O que usamos no lugar
Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn para volumes Kubernetes-native.
Nota de engenharia
Migração de volume via snapshot + restauração.

Virtual Cloud Network (VCN)

O que usamos no lugar
Binadit Private Infrastructure. VLANs isoladas com WireGuard para acesso site-to-site e de operadores.
Nota de engenharia
Os conceitos de OCI VCN (subnets, route tables, NAT gateways) mapeiam diretamente para o networking cloud padrão.

Functions (FaaS)

O que usamos no lugar
Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.
Nota de engenharia
A migração é mecânica; o OCI Functions é construído sobre o Fn Project, pelo que o modelo de runtime é portável.

Streaming (Kafka-compatible)

O que usamos no lugar
Binadit Managed Cloud Platform. Apache Kafka ou Redpanda, compatível com o protocolo Kafka.
Nota de engenharia
A migração do Kafka é um redirecionamento de producer/consumer; replicação de dados via MirrorMaker.

API Gateway

O que usamos no lugar
Binadit Managed Cloud Platform. Traefik ou Kong, com rate limiting e OIDC na edge.
Nota de engenharia
A KrakenD tem sede em Espanha e é uma forte escolha soberana.

Load Balancer

O que usamos no lugar
Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.
Nota de engenharia
Load balancing L4/L7 padrão.

Vault (KMS)

O que usamos no lugar
Binadit Private Infrastructure. Vault Transit para gestão de chaves, com chaves suportadas por HSM onde o regime de compliance o exigir.
Nota de engenharia
O Vault é a resposta soberana de nível de produção.

Logging / Monitoring

O que usamos no lugar
Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrados com OpenTelemetry.
Nota de engenharia
A instrumentação com OpenTelemetry torna a migração do lado da aplicação mecânica.

Como migramos de Oracle Cloud (OCI)

Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.

  1. Weeks 1-4

    Database scope decision

    Map every Oracle DB-specific feature in use (PL/SQL, Oracle Text, partitioning, materialized views, hierarchical queries, Oracle Spatial). Decision point: full migration to PostgreSQL or hybrid (compatibility-critical workloads on an Oracle-compatible PostgreSQL distribution). This is the schedule-defining task.

  2. Weeks 4-10

    Infrastructure migration

    Compute, networking, storage moved to EU sovereign stack. K8s workloads moved. Object storage migrated with API rewrites where needed. CI/CD repointed.

  3. Weeks 8-24

    Database cutover

    Schema converted with ora2pg. Data migrated with logical replication or change-data-capture for live workloads. Application code reviewed for Oracle-specific SQL. Cutover window scheduled with full rollback plan.

5-year TCO on full Oracle exits (infrastructure + database): typically 50-70% cheaper. The largest savings come from eliminating Oracle DB licensing (per-core enterprise pricing is brutal) followed by EU IaaS being ~40% cheaper than OCI on equivalent specs. The database conversion project itself is the largest one-time cost but pays back inside year 2.

What about Oracle EU Sovereign Cloud?
Oracle EU Sovereign Cloud (launched 2023, regions in Madrid and Frankfurt) is operated by EU-resident Oracle staff with operational separation from non-EU Oracle. It is an improvement on the documentation story for many regulated workloads - but Oracle Corporation remains the legal owner of the data. For Schrems II analyses that turn on parent jurisdiction, it is not full sovereignty.
Can we keep Oracle DB and just leave OCI?
Yes. An Oracle-compatible PostgreSQL distribution maintains compatibility at the SQL and PL/SQL level for most workloads. For mid-complexity Oracle applications this is a viable path that does not require a full database rewrite.
How big is the database migration project really?
For a typical mid-market Oracle DB (50-500GB, modest PL/SQL surface, no Oracle-specific features beyond standard SQL): 3-6 months parallel-run, 2-4 weeks for the cutover itself. For a heavy PL/SQL or Oracle-feature-dependent application: 9-18 months. The honest scoping is best done by people who have done it before.
What about Oracle Fusion Apps and Oracle ERP Cloud?
These are SaaS, not infrastructure - same conversation as Microsoft 365 or Salesforce. The decision to move off them is strategic, not infrastructural. We focus on the OCI infrastructure layer; the SaaS migration is typically a separate project run by a business-systems consultancy.
Is OCI actually competitive on pricing?
OCI's headline IaaS pricing is competitive vs AWS/Azure/GCP. Where OCI gets expensive is the database licensing on cloud (Oracle DB BYOL costs are high). For pure compute, the EU sovereign stack is still 30-40% cheaper. For Oracle DB workloads, the comparison is dominated by the licence, not the compute.
How long does an Oracle exit take end-to-end?
For infrastructure-only (no DB migration): 8-14 weeks. For full exit including PostgreSQL migration: 6-18 months elapsed time depending on database complexity. The schedule risk is entirely on the database side.

Planeie a sua saída de Oracle Cloud (OCI).

Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.