EDB Postgres / EDB Postgres Advanced Server（EPAS）

Writing rule: each feature = what it is + why it's genuinely strong + what happens at the edge.

1. The most complete Oracle compatibility layer among Postgres distributions What it really is: SPL (PL/SQL-style procedures, functions, triggers, packages), Oracle-compatible data types / SQL / system functions / data-dictionary compatibility views, MERGE, plus the EDB\Plus, EDB\Loader, DRITA, EDB\*Wrap, OCL toolchain (EPAS 16 official docs, reviewed 2026-09-28); enhanced connectors supporting REF_CURSOR, named parameters, VARCHAR2/STRUCT/ARRAY, multiple OUT/INOUT parameters (EDB official migration tooling docs). This is the shortest path to "run Oracle code with minimal changes." Edge truth: what's compatible is the "dialect," not a replica of the Oracle kernel. There are explicit gaps in partition-table uniqueness semantics, full-text search, ASM, table compression, external tables (see Deep Dives 1–2), and empty-string vs NULL semantic differences require explicit handling via switches like edb_redwood_strings. A checked box in the compatibility matrix ≠ the business workload will just run; heavy dependencies need item-by-item POCs.
2. Community PostgreSQL track + a commercial party accountable What it really is: EPAS 18.x keeps merging upstream PostgreSQL point releases (18.1→18.6, 2025-11 to 2026-08), giving enterprises a 24×7 support and security-patch party on the hook; EDB claims upstream contributions to PostgreSQL 18 in OAuth, the optimizer, and extension_control_path (2025-09 press release, vendor statement). Edge truth: "based on open source" ≠ "freely swappable." Leaving EPAS means dealing with SPL packages, Oracle-compatible objects, and OCL driver dependencies; and the commercial enhancements themselves become upgrade dependencies — PGE 18.2.0's release notes once recorded a password_profiles feature that broke pg_upgrade (see Deep Dive 7). You buy "someone is responsible"; the price is a new vendor dependency.
3. Two distribution tracks: PGE guards PG compatibility, EPAS carries Oracle migration What it really is: when Oracle compatibility isn't needed, the lighter PGE (PG behavioral compatibility + TDE + PGD replication optimizations + WAL pacing + diagnostic enhancements) avoids paying for and testing a compatibility layer you won't use; go EPAS when migrating Oracle. One vendor offering "light and heavy" options. Edge truth: the product / subscription / component matrix is complex (EPAS, PGE, PGD, EPRS, PEM, LiveCompare, Cloud Service, Hybrid Management…); picking the wrong distribution means reinstalling, retesting, and entitlement rework. The first thing to settle before a POC is "do we actually need Oracle compatibility mode?"
4. Kernel-level TDE (EPAS / PGE 15+) What it really is: transparent data encryption implemented in the kernel rather than as an extension, encrypting data files + WAL + query temp files, transparent to applications; keys can integrate with external KMS via PGDATAKEYWRAPCMD/UNWRAPCMD (e.g., HashiCorp Vault transit engine) (EDB official docs, reviewed 2026-09-28). This is a capability long missing from community PostgreSQL and a hard requirement in compliance scenarios (finance, 政企 zhèngqǐ — government and state-owned enterprises). Edge truth: TDE is a decision made at initdb time (can't be toggled after the fact on Cloud Service); it carries CPU/memory overhead; the backup chain must be adjusted accordingly — pgBackRest's official docs explicitly require disabling archive-header-check and checksum-page for EDB TDE (because EDB TDE computes checksums on encrypted pages); key management for remote replicas is an extra ops surface. What gets encrypted is "data at rest"; data in transit and in memory is out of scope.
5. An HA gradient from EFM primary/standby to PGD multi-master, from a single vendor What it really is: EFM manages streaming-replication-based primary/standby automatic failover (witness nodes + arbitration + STONITH, working out of the box); PGD offers cross-region active-active multi-master. Oracle migration projects no longer need to assemble HA from multiple vendors. Edge truth: EFM doesn't change streaming replication's inherent RPO trade-off (async can lose tail transactions; sync sacrifices write availability when the replica is unreachable); split-brain protection, old-primary fencing, and client reconnect remain whole-design questions; PGD's multi-master conflict management is no substitute for strongly consistent transactions (see Deep Dive 8); and long-term use of EFM, PGD, MTK enhanced capabilities, enhanced connectors, and LiveCompare all require an EDB database subscription — HA capability is deeply tied to the subscription.

Each item = mechanism + edge behavior + selection implication + source.

Deep Dive 1 (SQL layer): "Syntax passes" in Oracle compatibility ≠ "semantic equivalence" — partitioned uniqueness as an example

• Mechanism: EPAS 18's official docs explicitly list Oracle-compatibility partitioning limitations — non-partition-key columns may participate in primary / unique keys on partitioned tables, but the constraint is only built on child partitions; the key is not auto-created on new partitions; uniqueness does not span the whole partition hierarchy; interval / automatic partitioning only supports single-column keys, with DEFAULT, MAXVALUE, NULL/NaN/Infinity and other restrictions.
• At the edge: a partitioned table migrated from Oracle has CREATE TABLE statements that "run fine," but the global unique constraint has silently degraded to "unique within a partition." Cross-partition uniqueness the business relied on in Oracle needs application-layer or extra mechanisms to make up; a missing key on a new partition raises no error — it just silently stops protecting you.
• Selection implication: an Oracle-compatibility POC must include "constraint semantics" tests, not just "can this statement execute"; constraint definitions found in the data dictionary must be checked item by item against Oracle semantics.
• Source: EDB official EPAS 18 docs, Oracle compatibility partitioning limitations page (reviewed 2026-09-28) — official docs.

Deep Dive 2 (Migration & ecosystem): MTK auto-migration stops at "unsupported objects"

• Mechanism: the Migration Toolkit's official docs are explicit — objects using unsupported features cannot be migrated; Oracle full-text search is implemented differently, so MTK cannot migrate objects using it; ASM, table compression, and external tables are unsupported / cannot-be-directly-equivalent domains; after multi-profile migration, profiles must be manually assigned to users.
• At the edge: the official suggested alternatives (compressed file systems, staging tables + EDB\*Loader) are workarounds, not semantic equivalents — compression ratios, load paths, and ops models all change. In a "90% automated migration" project, the remaining 10% is usually full-text search, external-table integration, and compression strategies — the parts most deeply coupled to surrounding systems, and the parts effort estimates most often miss.
• Selection implication: the first step of migration assessment is pulling the "unsupported object list" for manual estimation, not looking at the "support percentage" first; workaround performance and ops semantics need revalidation.
• Source: EDB official Migration Toolkit v55 docs (reviewed 2026-09-28) — official docs.

Deep Dive 3 (Migration & ecosystem): LiveCompare's hash-comparison mechanics and blind spots

• Mechanism: LiveCompare defaults to comparison_algorithm = block_hash: fetched data blocks are hashed at block level first (a hash of hashes, like a two-level Merkle tree); a block hit skips the whole block, a miss falls back to row_hash to locate differing rows; cross Oracle/PG comparison uses a "common hash" — each row rendered as text (PG side fits timestamp / numeric / bytea into Oracle-style representation) then MD5'd. There's also a --conflicts mode comparing only primary-key rows touched by PGD/BDR conflict logs.
• At the edge: hash comparison's speed advantage rests on "consistent representation" — BLOB/CLOB/NCLOB default to comparing only the first 2000 characters; an Oracle-side whole-row text representation exceeding 4000 characters triggers ORA-01489 and aborts that table's comparison; Oracle 10g can only use the slowest full_row. More importantly: LiveCompare verifies "are data rows consistent," not constraint semantics, sequence current values, privileges, or profile bindings — it complements Deep Dives 1–2, it doesn't replace them.
• Selection implication: when writing LiveCompare into migration acceptance criteria, also define "hash algorithm + excluded columns (e.g., ROWID / ORA_ROWSCN) + precision tolerance + manual check items (constraints/sequences/privileges)," or the acceptance report will give you false confidence.
• Source: EDB official LiveCompare docs (settings page and 2.0 release notes, reviewed 2026-09-28) — official docs; long-term use requires a subscription (official migration tooling docs).

Deep Dive 4 (Storage & transactions): Long transactions freeze VACUUM — one report query can bloat the whole database

• Mechanism: EPAS inherits PostgreSQL MVCC: UPDATE/DELETE produce dead tuples reclaimed by VACUUM; any transaction holding an old snapshot (long queries, idle-in-transaction connections, prepared transactions) raises the whole database's xmin horizon, so autovacuum can't reclaim dead tuples for the entire database. Exhausting the 32-bit transaction ID space triggers wraparound protection, and the cluster enters a write-refusing emergency state.
• At the edge: an 8-hour report transaction on the primary doesn't show up as "slow report" — it shows up as whole-database table bloat, index bloat, and steadily rising disk usage, while autovacuum looks busy but reclaims nothing. The firefight is an idle_in_transaction_session_timeout circuit breaker + finding and handling the offender (check pg_stat_activity.backend_xmin), not adding disk. max_slot_wal_keep_size (PG13+) is the analogous safety valve for replication slots, but unset by default means infinite retention.
• Selection implication: this is a "mechanism tax" no commercial edition exempts you from. Selection must confirm the team has PostgreSQL ops fundamentals (autovacuum tuning, long-transaction governance, datfrozenxid inspection) rather than assuming "the commercial edition handles it automatically"; report workloads always go to replicas.
• Source: PostgreSQL community consensus (multiple production ops write-ups, collected 2026-09-28); EPAS doesn't change this mechanism (EDB claims no changes; PGE docs only mention peripheral optimizations like WAL pacing).

Deep Dive 5 (Connections & concurrency): One connection, one backend process — connection storms exhaust CPU/memory first

• Mechanism: PostgreSQL (including EPAS) maps each client connection to one backend OS process with real memory overhead; max_connections is a hard ceiling, and beyond it new connections get FATAL: too many connections.
• At the edge: the multiplicative effect of microservice instances × per-instance connection pools, or serverless bursts, can push connections to the ceiling in the dead of night at low business load — the symptom is "apps can't connect," while the database itself is lightly loaded. The fix is pooling like PgBouncer (transaction mode), with pool sizes derived backwards from the database's actual budget rather than forwards from app instance counts.
• Selection implication: EPAS's commercial nature doesn't change the process model; any "high-concurrency access" POC must include connection topology (direct / PgBouncer / app pools) as a mandatory test item.
• Source: PostgreSQL community consensus (collected 2026-09-28).

Deep Dive 6 (Replication & DR): EFM automatic failover ≠ automatically eliminating the data-loss window; idle replication slots can fill the primary's disk

• Mechanism: EFM manages streaming-replication primary/standby + automatic failover. Under async replication, tail transactions not yet received by the standby are inevitably lost when the primary dies (RPO>0); under sync replication, writes block when the only sync standby is unavailable (sacrificing availability for zero loss). On the other side: the primary's WAL retention promise for replication slots is unbounded — if a standby goes offline and its slot isn't dropped, the primary's pg_wal piles up without limit until the disk fills and the primary refuses writes.
• At the edge: the most common "double kill" is: standby hardware failure → slot goes idle → nobody gets alerted → days later the primary's disk fills → primary stops accepting writes. This isn't an EFM bug; it's the combination of "slot retention semantics + missing monitoring." max_slot_wal_keep_size should be standard, at the cost that an over-limit slot becomes lost and the standby must be rebuilt — trading "a rebuildable standby" for "a primary that never dies."
• Selection implication: HA design reviews must answer four things together: RPO choice (sync/async/quorum), split-brain protection (STONITH/arbitration), old-primary fencing, and client reconnect; replication-slot monitoring (idle pg_replication_slots + lag bytes) belongs on the go-live checklist.
• Source: EFM official migration tooling docs (reviewed 2026-09-28) — official docs; replication-slot mechanics are PostgreSQL community consensus.

Deep Dive 7 (Ops & upgrades): Major-version upgrades aren't patches; commercial enhancements become upgrade dependencies

• Mechanism: PostgreSQL major versions have incompatible data-file formats; upgrade paths are pg_upgrade (--link hard links, minutes of downtime), logical-replication cutover, or dump/restore; statistics aren't carried over post-upgrade so ANALYZE is mandatory, and each extension's version compatibility must be confirmed.
• At the edge: PGE 18.2.0's release notes recorded a password_profiles feature breaking pg_upgrade — a commercial-enhancement bug can jam the entire upgrade window, and such issues can't be found in community PG upgrade manuals; you can only wait for the vendor fix. Also, the BART backup tool is no longer officially supported on PG/EPAS 14+ and must move to Barman or pgBackRest (EPAS 18 release notes, official docs) — backup-toolchain migration is part of upgrade planning.
• Selection implication: write "major-version upgrade rehearsal" into the first year's ops plan; before upgrading, check both halves of the EPAS release notes item by item ("upstream merges + EDB enhancement changes"); if backups still use BART, switch before upgrading to PG14+.
• Source: EDB official EPAS 18 release notes, PGE 18.2 release notes (reviewed 2026-09-28) — official docs; pg_upgrade mechanics are community consensus.

Deep Dive 8 (Consistency & multi-master): PGD's conflict management is no substitute for strongly consistent transactions

• Mechanism: PGD (formerly BDR) is a logical-replication-based multi-master solution; official claims include conflict management, data-loss protection, throughput 5× native logical replication, and up to five-nines availability — all EDB official statements. Its default semantics are async / eventual convergence: when two nodes concurrently modify the same business key, conflict rules decide — there are no cross-node strongly consistent transactions.
• At the edge: third-party analysis (druce/dbengines, 2026-06-04, high confidence) notes that even the vendor's own Jepsen-framework testing once found rare update-conflict data divergence. Conflict-handling strategy, replication-set partitioning, and whether "last write wins" is acceptable are all application-and-data-model design questions — they need answers before adopting PGD, not after going live.
• Selection implication: if the target architecture uses PGD, the Oracle migration POC must include it (EDB's official migration guide recommends the same), since application and database design may need adjustment; treat the official "five nines / 5× throughput" as marketing claims pending POC validation.
• Source: EDB official migration tooling docs (reviewed 2026-09-28) — official docs; druce/dbengines third-party analysis (2026-06-04) — third-party assessment, pending further verification.

Deep Dive 9 (Licensing & cost): uniCore/Server subscription metering boundaries in elastic and HA scenarios

• Mechanism: EDB's current subscription agreement: software rights are term-limited, non-transferable subscriptions; the unit of measure (UOM) is uniCore (physical cores or vCores/vCPUs allocated to VMs) or Server, per the order form; commercial software rights exist only while subscription fees are current (reviewed 2026-09-28).
• At the edge: the real cost risk isn't the unit price (which isn't public anyway) but the metering boundaries — do HA standbys, DR nodes, read replicas, and test environments count? Are containers metered by request or limit? Do temporarily scaled-up vCPUs during peak events bill at peak or monthly? How are "vCores allocated to VMs" defined under Kubernetes? If these aren't nailed down in the quote/UOM terms, a three-year TCO model is built on sand. Also note: long-term use of EFM, PGD, MTK enhanced capabilities, enhanced connectors, and LiveCompare all require an EDB database subscription — "bought the database" and "can use the full toolchain" are two different things.
• Selection implication: during the quoting phase, turn "replicas/DR/testing/entitlement boundaries/overage scaling" into a written question list and require the vendor to answer at the order level; "cheaper than Oracle" is only a relative positioning, never convert it into a percentage without evidence.
• Source: EDB official subscription agreement (reviewed 2026-09-28) — official docs; pricing materials from 2005–2015 are outdated and must not be cited as current prices.

Writing rule: strengths need depth too. Each item = why it's true + edges and limits.

1. Genuinely less code rewriting for Oracle migration
   • Why it's true: SPL compatibility for PL/SQL packages/procedures/triggers + Oracle data types/dictionary views + MTK schema migration + LiveCompare data validation + Replication Server CDC as a safety net form a complete migration pipeline. Multiple user reviews (PeerSpot/TrustRadius) confirm "most Oracle packages needed no changes."
   • Edges and limits: what you save is "initial rewriting," not "total effort" — the semantic gaps in Deep Dives 1–2 (partition uniqueness, full-text search, ASM/compression/external tables) push work into the testing and integration phase; and the deeper you go (the more SPL, OCL, and Oracle dictionary views you use), the higher the cost of migrating back to community PG — "escaping Oracle" can become "moving into EDB."
   • Source: PeerSpot EPAS user reviews (cost-saving vs Oracle), TrustRadius testimonials (collected 2026-09-28); EDB official migration tooling docs. observed_version: EPAS 16/18 (2026-09).
2. PostgreSQL ecosystem reuse, gentle learning curve
   • Why it's true: the kernel is PG — drivers, ORMs, pgAdmin (officially supports EPAS 14–18, pgAdmin 4 v9.18 release notes), SQL syntax, and ops knowledge all carry over; existing PG DBA skills apply directly.
   • Edges and limits: what's reused is the "community PG ecosystem"; the EDB-specific layer (SPL debugging, EPAS-specific system views, the commercial toolchain) must be learned separately; availability of new community PG extensions/versions on EPAS follows EDB's certification cadence, not upstream release day. Greenfield projects with no Oracle compatibility needs pay for redundant capability.
   • Source: pgAdmin official release notes (v9.18); community consensus. observed_version: EPAS 14–18 / pgAdmin 4 v9.18 (2026-09).
3. A single commercial party accountable — someone answers the phone at 3 AM
   • Why it's true: patches, security updates, and incident troubleshooting have a clearly accountable commercial party; "good support" is a high-frequency phrase in user reviews; for finance / 政企 (government and SOE) compliance and audits, "vendor backing" is itself a procurement requirement.
   • Edges and limits: support solves "known issues get fixed by someone" — it doesn't replace architectural capability. Mechanism taxes like long-transaction bloat, replication slots filling disks, and PGD conflict design can only be taught by support, not waived; and support quality correlates strongly with subscription tier and regional team — spell out the SLA in the contract.
   • Source: PeerSpot/TrustRadius user reviews (collected 2026-09-28). observed_version: all EPAS versions (review period 2024–2026).
4. Kernel-level TDE, hard currency for compliance scenarios
   • Why it's true: community PG has long lacked native encryption at rest; EDB built TDE into the kernel (data files + WAL + temp files), transparent to applications, with a CloudNativePG operator path to external KMS — a deciding factor for some regulated-industry selections.
   • Edges and limits: TDE only solves "lost disks don't leak data," not in-transit / in-memory / backup-chain key management; it's an initdb-time decision, hard to change later; backup tooling needs parameter tuning (pgBackRest checksum-check disabling); it has CPU/memory overhead — measure under high-throughput workloads.
   • Source: EDB official TDE docs (CloudNativePG/CNPG operator, Cloud Service security pages, reviewed 2026-09-28). observed_version: EPAS/PGE 15+.
5. Relatively complete migrate-validate-HA-monitor toolchain
   • Why it's true: MTK (migration) + LiveCompare (validation) + Replication Server (CDC/rollback) + EFM (auto-failover) + PEM (monitoring/management) come from one vendor, so Oracle migration projects don't assemble across vendors — especially good for traditional enterprise teams short on senior PG DBAs.
   • Edges and limits: "complete" assumes the whole family is inside the subscription — long-term use of LiveCompare, Replication Server, EFM, and enhanced connectors all require an EDB database subscription; users report default monitoring is still insufficient and want more (PeerSpot); the more complete the toolchain, the higher the exit cost.
   • Source: EDB official migration tooling docs; PeerSpot user reviews (collected 2026-09-28). observed_version: EPAS 16/18 (2026-09).

• One-line positioning: EDB Postgres Advanced Server is a distribution bundling the PostgreSQL kernel, an Oracle-migration compatibility layer, and commercial support/HA/security tooling into one enterprise platform; its value isn't in replacing community PostgreSQL, but in reducing organizational risk for large Oracle migrations and regulated-enterprise Postgres standardization.
• Good for:
  • Large enterprise migration projects carrying heavy Oracle technical debt (lots of PL/SQL packages and stored procedures), where management will pay for "migration success rate" rather than "absolute lowest cost";
  • Regulated industries (finance / 政企 government & SOEs) needing an accountable commercial support party + kernel-level TDE + audit-compliant Postgres standardization;
  • Hybrid-cloud teams needing one vendor to cover "auto-failover → cross-region multi-master" with the same commercial stack across on-prem / multi-cloud / regulated environments;
  • Traditional enterprise IT short on senior PG DBAs, wanting the commercial toolchain (MTK/LiveCompare/EFM/PEM) to lower the ops bar.
• Not for:
  • Greenfield projects with no Oracle baggage — community PostgreSQL is free and equivalent; EDB's compatibility layer is pure overhead;
  • Deeply cloud-native teams comfortable with cloud-managed PG (RDS / Aurora / AlloyDB) — self-managed EDB carries far more ops responsibility;
  • Budget-sensitive startups/SaaS (users already report it isn't worth it), and teams wanting "install and forget" with no DBA investment;
  • Teams needing extreme PG kernel customization or a purely open-source, zero-commercial-lock-in technology path.
• Migration cost:
  • from_oracle: low-medium → medium. Light PL/SQL can be close to "run with minimal changes"; heavy dependencies (partition semantics, full-text search, ASM/compression/external tables, advanced packages) usually land at "medium" after item-by-item POCs, with part of the effort reclaimed in the testing/integration phase.
  • from_postgres: low. Protocol/ecosystem/ops knowledge carries over; but enabling EPAS Oracle-compatible objects and the commercial toolchain creates new exit costs — count "cost of moving in" and "cost of moving out" together.
  • from_mysql: medium-high. EDB's migration toolchain supports MySQL as a source, but there's no MySQL protocol compatibility — application-layer rework dominates; MySQL → PG is a dialect migration anyway, and EDB's Oracle compatibility helps little here.

• Version info: EDB official EPAS release notes (18.1 2025-11-25 → 18.6 2026-08-13; BART retirement on 14+; upstream point-release merge notes) — https://www.enterprisedb.com/docs/epas/latest/epas_rel_notes/ (reviewed 2026-09-28)
• Oracle compatibility matrix: EPAS 16 official docs, Oracle compatibility developer guide — https://www.enterprisedb.com/docs/epas/16/fundamentals/epas_fundamentals/epas_compat_ora_dev_guide/ (reviewed 2026-09-28)
• Oracle compatibility partitioning limitations: EPAS 18 official docs — https://www.enterprisedb.com/docs/epas/latest/reference/oracle_compatibility_reference/04_partitioning_commands_compatible_with_oracle_databases/limitations/ (reviewed 2026-09-28)
• PGE positioning and kernel enhancements: EDB official PGE 14/16 docs — https://www.EnterpriseDB.com/docs/pge/16/ (reviewed 2026-09-28)
• Migration toolchain (MTK / LiveCompare / Replication Server / EFM / enhanced connectors) and subscription requirements: EDB official advocacy docs — https://github.com/enterprisedb/docs/blob/HEAD/advocacy_docs/migrating/oracle/edb_migration_tools.mdx (reviewed 2026-09-28)
• MTK functional boundaries: Migration Toolkit v55 official docs — https://www.enterprisedb.com/docs/migration_toolkit/latest/04_functionality_overview/ (reviewed 2026-09-28)
• LiveCompare comparison mechanics: official settings docs — https://www.enterprisedb.com/docs/livecompare/2/settings/; 2.0 release notes (reviewed 2026-09-28)
• TDE capability and key management: EDB official CloudNativePG TDE docs, Cloud Service security pages; pgBackRest official docs' backup parameter requirements for EDB TDE — https://github.com/enterprisedb/docs/blob/HEAD/advocacy_docs/supported-open-source/pgbackrest/04-recommended_settings.mdx (reviewed 2026-09-28)
• Subscription licensing terms: EDB Subscription, Support and Services Agreement — https://www.enterprisedb.com/enterprisedb-subscription-support-and-services-agreement-10 (reviewed 2026-09-28)
• Independent third-party profile: druce/dbengines engines/edb-postgres.md (2026-06-04, high confidence; EPAS/PGE relationship, PGD eventual consistency and the Jepsen-found divergence assessment) — https://github.com/druce/dbengines/blob/HEAD/engines/edb-postgres.md
• User reputation: PeerSpot EPAS reviews (cost, monitoring, JSONB, docs, pricing feedback) — https://www.peerspot.com/products/edb-postgres-advanced-server-reviews; TrustRadius comparison page ("PPAS quite complex" learning-curve testimony) (reviewed 2026-09-28)
• EDB's PG18 upstream contributions: DBTA 2025-09-29 report (OAuth, optimizer, extension_control_path; vendor press-release statement)
• EDB 2025–2026 platform news: WarehousePG (Greenplum fork, Apache 2.0, DBTA 2025-12-23) — an EDB PG AI platform item, not counted as EPAS single-node kernel capability
• Cloud competition boundary: EDB official Aurora comparison whitepaper (SLA figures are vendor marketing statements); AlloyDB third-party reporting relaying Google's official statement (reviewed 2026-09-28)
• Inherent PG mechanics (MVCC/replication slots/connection model/pg_upgrade): PostgreSQL community consensus, cross-validated by multiple production ops write-ups (collected 2026-09-28)
• Next review suggestions: track EPAS 18.7+ release notes (upstream PG 18.x merges and EDB enhancement changes), independent testing of PGD conflict semantics, scaled collection of Chinese community practice posts; re-verify metering boundaries if the EDB subscription agreement changes.