Databázová modernizace v roce 2026 — NewSQL, distribuované databáze a migrace z legacy systémů

Databáze jsou srdce každého informačního systému. A přesto v roce 2026 většina českých enterprise organizací běží na architekturách navržených v devadesátých letech — single-node Oracle, monolitický SQL Server, MySQL bez shardingu. Modernizace databázové vrstvy není sexy téma, ale je to nejkritičtější infrastrukturní rozhodnutí, které v následujících třech letech uděláte.

Proč modernizovat právě teď¶

Tři konvergentní tlaky nutí organizace k akci:

Regulatorní požadavky. NIS2 a DORA vyžadují prokazatelnou odolnost kritických systémů. Single-node databáze s manuálním failoverem nesplňuje požadavky na RPO/RTO, které regulátoři od roku 2025 vymáhají. Banky, pojišťovny a energetické firmy musí demonstrovat automatický failover s RPO < 1 sekunda.

Datový objem. IoT, AI/ML pipeline, real-time analytics — objem dat roste exponenciálně. Tradiční vertikální škálování (větší server, více RAM) naráží na fyzické limity a astronomické náklady. Oracle RAC licence za desítky milionů korun ročně jsou pro střední firmy neudržitelné.

Cloud-native architektura. Microservices, Kubernetes, multi-region deployment — moderní aplikační architektura vyžaduje databáze, které umí horizontálně škálovat, automaticky se replikovat a fungovat across regionů. Monolitická databáze na jednom serveru v jednom datovém centru je single point of failure, který si nemůžete dovolit.

Landscape databázových technologií v 2026¶

PostgreSQL 17 — open-source king¶

PostgreSQL pokračuje v dominanci open-source relačního světa. Verze 17 (září 2025) přinesla:

• Incremental backup: pg_basebackup --incremental — zálohují se pouze změněné bloky od posledního full backupu. Dramaticky snižuje storage a čas zálohování pro multi-TB databáze.
• Logical replication improvements: Failover logical replication slots. Subscriber může pokračovat v replikaci po failoveru primary. Kritické pro zero-downtime migrace a CDC pipeline.
• JSON_TABLE: SQL/JSON standard pro dotazování JSON dat jako relačních tabulek. Konečně plná parity s Oracle 23ai JSON funkcionalitou.
• Performance: Vylepšený query planner pro partitioned tables. Bulk inserts 2× rychlejší díky stream I/O pro COPY. Vacuum 2× efektivnější pro velké tabulky.

PostgreSQL s rozšířeními (Citus pro distributed queries, pgvector pro embeddings, TimescaleDB pro time-series) pokrývá 90 % use cases, které dříve vyžadovaly specializované databáze. Je to naše default doporučení pro nové projekty.

CockroachDB — distributed SQL pro globální aplikace¶

CockroachDB je NewSQL databáze — kombinuje ACID transakce relační databáze s horizontální škálovatelností NoSQL. Architektura inspirovaná Google Spanner, ale bez závislosti na atomových hodinách.

Klíčové vlastnosti: - Automatický sharding a rebalancing: Data se automaticky distribuují across nodes. Přidáte node → data se rebalancují. Žádný manuální sharding. - Multi-region deployment: Configurable replication zones. Data můžete pinovat do konkrétních regionů (GDPR compliance — data EU občanů zůstanou v EU). - Serializable isolation: Nejsilnější izolační úroveň by default. Žádné phantom reads, žádné write skew. Pro finanční aplikace klíčové. - PostgreSQL wire protocol: Kompatibilní s PostgreSQL klientskými knihovnami. Existující aplikace s PostgreSQL mohou migrovat s minimálními změnami. - Survivability: Přežije výpadek celého regionu bez manuálního zásahu. Automatický leader election, automatická re-replikace.

Kdy použít: Globálně distribuované aplikace, multi-region deployment, finanční systémy vyžadující serializable transakce, systémy kde downtime = regulatorní problém.

Kdy nepoužít: Single-region deployment s < 1 TB dat (overkill), analytické workloady (OLAP), systémy s extrémně nízkou latencí < 1 ms (distributed consensus přidává latenci).

Licence: Core verze je open-source (BSL → Apache 2.0 po 3 letech). Enterprise features (CDC, backup to S3, RBAC) vyžadují licenci.

YugabyteDB — PostgreSQL-kompatibilní distributed SQL¶

YugabyteDB je přímý konkurent CockroachDB s jedním zásadním rozdílem: plná PostgreSQL kompatibilita na úrovni query engine. Nejen wire protocol, ale kompletní PostgreSQL parser a executor (fork PostgreSQL 11.2, postupně aktualizovaný).

Rozdíly oproti CockroachDB: - Lepší PostgreSQL kompatibilita (extensions, PL/pgSQL, triggers) - Podpora YSQL (distributed PostgreSQL) i YCQL (Cassandra-compatible API) - Slabší multi-region automatizace (vyžaduje více manuální konfigurace) - Open-source pod Apache 2.0 (bez BSL omezení)

Kdy použít: Migrace z PostgreSQL kde potřebujete distribuovanost. Workloady kombinující OLTP + lehké OLAP. Organizace preferující plně open-source řešení.

TiDB — MySQL-kompatibilní distributed SQL¶

TiDB od PingCAP je MySQL-kompatibilní distribuovaná databáze. Pro organizace s existujícím MySQL stackem je nejpřirozenější cesta k distribuované architektuře.

Architektura: - TiDB Server: Stateless SQL vrstva (MySQL protocol). Horizontálně škálovatelná. - TiKV: Distributed key-value storage (Rust, Raft consensus). CNCF graduated project. - TiFlash: Sloupcový engine pro analytické dotazy. Realtime HTAP — jeden systém pro OLTP i OLAP.

Killer feature: HTAP (Hybrid Transactional/Analytical Processing). Transakční data se automaticky replikují do sloupcového TiFlash engine. Analytické dotazy běží na TiFlash bez dopadu na transakční výkon. Žádný ETL, žádný separate data warehouse pro operační analytiku.

Kdy použít: MySQL migrace, HTAP workloady, organizace potřebující real-time analytics nad transakčními daty.

Vitess — škálování MySQL bez rewrite¶

Vitess (CNCF graduated) není nová databáze — je to middleware vrstva nad MySQL, která přidává horizontální škálování. Vyvinutý původně v YouTube pro škálování MySQL na miliardy řádků.

Jak funguje: - VTGate: Query router, parsuje SQL, routuje na správný shard - VTTablet: Agent na každém MySQL instanci, health checking, failover - Topology Service: etcd/ZooKeeper pro metadata a koordinaci

Výhoda: Existující MySQL aplikace migrují s minimálními změnami. MySQL engine zůstává — Vitess přidává sharding, connection pooling, online schema changes (gh-ost/pt-osc integrovaná).

Limity: Cross-shard transakce jsou drahé. JOIN across shardů omezený. Vyžaduje pochopení sharding key designu.

Kdy použít: Existující velké MySQL deployment, které potřebuje horizontální škálování. Organizace, které nechtějí migrovat z MySQL na novou databázi.

AlloyDB a Aurora — managed distributed varianty¶

Google AlloyDB: PostgreSQL-kompatibilní managed databáze. Storage separovaný od compute (disaggregated architecture). 4× rychlejší než vanilla PostgreSQL na transakčních workloadech (Google benchmarky). Columnar engine pro analytiku. AI-driven adaptive storage. Fully managed — zero ops.

Amazon Aurora: MySQL/PostgreSQL kompatibilní managed databáze. 6-way replication across AZs. Storage auto-scaling do 128 TB. Aurora Serverless v2 pro variable workloady. Aurora Machine Learning pro in-database ML inference.

Kdy použít: Organizace plně committnuté ke konkrétnímu cloudu (GCP resp. AWS), kde vendor lock-in není problém a nulový ops overhead je priorita.

Migrace z legacy databází — praktický průvodce¶

Oracle → PostgreSQL¶

Nejčastější migrace v českém enterprise. Oracle licence stojí statisíce až miliony ročně. PostgreSQL je zdarma a pro 95 % workloadů funkčně ekvivalentní.

Kroky migrace:

1. Assessment: Inventarizace Oracle-specific features. PL/SQL procedury, materialized views, Oracle Text, spatial, partitioning, RAC. Nástroj: ora2pg (open-source) generuje assessment report s complexity skóre.

2. Schema konverze: ora2pg konvertuje DDL, PL/SQL → PL/pgSQL, triggery, sequences. Automaticky zvládne ~70 % konverze. Zbylých 30 % vyžaduje manuální práci — Oracle-specific funkce (DECODE, NVL, ROWNUM, hierarchical queries s CONNECT BY).

3. Data migrace: ora2pg pro batch export. Pro velké tabulky (100M+ řádků) použijte paralelní export s --jobs. Foreign Data Wrapper (oracle_fdw) pro inkrementální sync během dual-run periody.

4. Application layer: ORM-based aplikace (Hibernate, SQLAlchemy) typicky vyžadují minimální změny — změní se dialect. Raw SQL vyžaduje audit — Oracle-specific syntaxe (MERGE, analytic functions syntax, outer join (+) syntaxe).

5. Testing: Srovnávací testy na produkčních datech. Query plan analýza — PostgreSQL optimizer se chová odlišně od Oracle CBO. Indexing strategie může vyžadovat přehodnocení.

6. Dual-run: Obě databáze běží paralelně. Writes jdou do obou, reads se postupně přesouvají. Monitoring diskrepancí. Typicky 2–4 týdny.

Časový odhad: Jednoduchá databáze (< 100 tabulek, žádné PL/SQL) = 2–4 týdny. Komplexní (500+ tabulek, PL/SQL, RAC) = 3–6 měsíců.

SQL Server → PostgreSQL¶

Jednodušší než Oracle migrace díky bližší SQL kompatibilitě. Hlavní rozdíly:

• T-SQL → PL/pgSQL (jiná syntax pro IF/WHILE/CURSOR, error handling TRY/CATCH → BEGIN/EXCEPTION)
• IDENTITY → GENERATED ALWAYS AS IDENTITY
• TOP → LIMIT
• CROSS APPLY → LATERAL JOIN
• SQL Server Agent jobs → pg_cron nebo OS-level scheduling
• SSRS → Grafana/Metabase/Apache Superset

Nástroj: pgloader (open-source) pro schema + data migrace z MSSQL. sqlserver_fdw pro inkrementální sync.

MySQL → PostgreSQL (nebo naopak)¶

Přechod mezi MySQL a PostgreSQL je relativně přímočarý díky SQL standardu. Hlavní pain pointy:

• AUTO_INCREMENT → SERIAL/GENERATED
• ENUM handling (MySQL native, PostgreSQL custom type)
• Case sensitivity (MySQL default case-insensitive collation)
• GROUP BY strict mode (PostgreSQL striktní, MySQL laxní)
• JSON functions (odlišná syntax)

pgloader zvládá automatickou migraci včetně type mappingu.

Rozhodovací framework¶

Jak vybrat správnou databázi pro váš use case? Projděte tento rozhodovací strom:

1. Jaký je primární workload? - OLTP (transakce, CRUD) → relační databáze - OLAP (analytika, reporting) → columnar (ClickHouse, DuckDB, BigQuery) - HTAP (obojí) → TiDB, AlloyDB, CockroachDB + analytický engine - Time-series → TimescaleDB (PostgreSQL extension), InfluxDB - Document store → MongoDB, PostgreSQL JSONB - Graph → Neo4j, Apache AGE (PostgreSQL extension) - Vector search → pgvector, Milvus, Qdrant

2. Jaký je objem dat a růst? - < 100 GB, stabilní → single-node PostgreSQL/MySQL - 100 GB – 1 TB, rostoucí → PostgreSQL s read replicas, partitioning - 1 – 10 TB → Citus (distributed PostgreSQL), Vitess (MySQL), CockroachDB - 10+ TB → CockroachDB, YugabyteDB, TiDB, cloud-native (Aurora, AlloyDB)

3. Jaké jsou požadavky na dostupnost? - 99.9 % (8.7h downtime/rok) → primary-standby s automatic failover (Patroni) - 99.99 % (52 min/rok) → multi-node cluster (CockroachDB, YugabyteDB) - 99.999 % (5.2 min/rok) → multi-region deployment, distributed consensus

4. Jaké jsou regulatorní požadavky? - Data residency (GDPR) → geo-partitioning (CockroachDB, YugabyteDB) - Audit trail → PostgreSQL pgaudit, CockroachDB SQL audit logging - Encryption at rest → TDE (Transparent Data Encryption) nebo filesystem encryption - DORA/NIS2 compliance → demonstrable RPO < 1s, automated failover, DR testing

5. Jaký je budget? - Zero licence cost → PostgreSQL, MySQL, MariaDB, CockroachDB Core - Managed service → Aurora, AlloyDB, Cloud SQL, Azure Database - Enterprise support → CockroachDB Enterprise, YugabyteDB Anywhere, EDB PostgreSQL

PostgreSQL High Availability — production-ready setup¶

Pro organizace, které nepotřebují distribuovanou databázi, ale vyžadují high availability, je PostgreSQL s Patroni gold standard:

Architektura: - 3 PostgreSQL nodes (1 primary, 2 replicas) - Patroni na každém node (cluster management, automatic failover) - etcd cluster (3 nodes) pro distributed consensus (leader election) - HAProxy nebo PgBouncer pro connection routing - Barman nebo pgBackRest pro continuous backup

Failover scénář: 1. Primary node umře (hardware failure, kernel panic, network partition) 2. Patroni detekuje výpadek (zdravotní kontroly každých 10s) 3. etcd leader election — zbývající repliky volí nový primary 4. Patroni promuje repliku s nejmenším replication lagem na primary 5. HAProxy automaticky přesměruje traffic na nový primary 6. Celý failover < 30 sekund, RPO ≈ 0 (synchronní replikace)

Monitoring: - Prometheus + postgres_exporter pro metriky (connections, replication lag, transaction rate, cache hit ratio) - Grafana dashboard s alertingem na replication lag > 1s, connections > 80% max, WAL archiving delay - PgHero pro query performance analysis a index recommendations

Observability pro databáze¶

Modernizace bez observability je slepý let. Klíčové metriky:

• Query performance: p50/p95/p99 latence per query type. pg_stat_statements pro PostgreSQL. Slow query log s threshold 100ms.
• Connection management: Active/idle/waiting connections. Connection pool utilization. PgBouncer stats.
• Replication health: Replication lag v bytech a sekundách. WAL sender/receiver stats.
• Storage: Table/index bloat (dead tuples). Disk usage trend. Vacuum effectiveness.
• Lock contention: Lock waits > 1s. Deadlock frequency. pg_stat_activity pro blocked queries.

Nejčastější chyby při modernizaci¶

1. Lift and shift bez optimalizace. Přenesení Oracle schema 1:1 do PostgreSQL bez přehodnocení indexing strategie, partitioning a query patterns. PostgreSQL optimizer pracuje jinak — co bylo rychlé v Oracle může být pomalé v PostgreSQL a naopak.

2. Podceněný testing. Funkční testy nestačí. Potřebujete performance testy na produkčních datech — ne na 1 % sample. Query, který běží 10 ms na 1M řádků, může běžet 10 minut na 100M řádků s chybějícím indexem.

3. Ignorování connection managementu. PostgreSQL vytváří nový proces per connection (fork model). 1000 connections = 1000 procesů. Bez connection pooleru (PgBouncer, Odyssey) se PostgreSQL pod zátěží zhroutí. Nastavte PgBouncer VŽDY.

4. Big bang migrace. Přepnutí všeho v pátek večer. Místo toho: strangler fig pattern — nové features na nové databázi, postupná migrace existujících. Dual-write perioda pro validaci.

5. Zanedbání backup strategie. “Máme replikaci, nepotřebujeme backup.” Replikace chrání proti hardware failure. Backup chrání proti logickým chybám — DROP TABLE, corrupted data, ransomware. PITR (Point-in-Time Recovery) s WAL archivingem. Testujte restore pravidelně (quarterly).

6. Vendor lock-in v cloudu. Aurora a AlloyDB jsou výborné produkty, ale migrace z nich je bolestivá. Pokud existuje šance na multi-cloud nebo on-prem návrat, zůstaňte u vanilla PostgreSQL/MySQL kompatibility.

Budoucnost: kam směřujeme¶

Serverless databáze se stávají mainstream. Neon (serverless PostgreSQL), CockroachDB Serverless, PlanetScale (serverless MySQL/Vitess) — platíte za spotřebu, ne za provisioned capacity. Ideální pro variable workloady a development/staging prostředí.

AI-native databáze integrují vektorové vyhledávání, embedding generování a ML inference přímo do databázového engine. PostgreSQL s pgvector + pgml umožňuje běžet embedding search i model inference v SQL dotazu. AlloyDB integruje Vertex AI přímo do query engine.

Disaggregated storage odděluje compute od storage. Neon, Aurora, AlloyDB — storage je distribuovaný a sdílený, compute se škáluje nezávisle. Branching (Neon) umožňuje vytvořit kopii celé databáze za sekundy pro testování nebo development.

Závěr¶

Databázová modernizace není jednorázový projekt — je to strategické rozhodnutí s dopadem na příštích 10 let. Správná volba dnes ušetří miliony na licencích, sníží operační zátěž a umožní škálování, které vaše aplikace budou potřebovat.

Naše doporučení pro české enterprise v 2026:

• Default volba: PostgreSQL 17 s Patroni HA. Pokrývá 90 % use cases. Zero licence cost, obrovská komunita, enterprise-grade stabilita.
• Distribuovaná potřeba: CockroachDB pro globální aplikace, YugabyteDB pro maximální PostgreSQL kompatibilitu, TiDB pro MySQL ekosystém.
• Migrace z Oracle: ora2pg + dual-run strategie. ROI typicky 12–18 měsíců (úspora na licencích).
• Cloud-native: Zvažte Neon (serverless PostgreSQL) pro development a variable workloady. Aurora/AlloyDB pro maximum managed experience (s vědomím lock-in).

Nejdůležitější krok? Začněte assessment. Zmapujte vaše databáze, jejich závislosti, Oracle/MSSQL-specific features a regulatorní požadavky. Bez assessmentu je jakékoli rozhodnutí střelba naslepo. CORE SYSTEMS vám s tím rádi pomůžeme.