Worlber

CYBERTEC PGEE in Saudi Arabia: what enterprise PostgreSQL adds for regulated workloads

Date Published

Most database renewal conversations start with a number that somebody else wrote. Oracle and Microsoft SQL Server are licensed per core, the renewal quote usually grows, and the infrastructure team gets asked the obvious question: can this run on PostgreSQL instead?

Community PostgreSQL can carry more enterprise workloads than most teams assume. What it does not give you on its own is encryption at rest with managed keys, masking controls for non-production copies, extended audit trails, and a vendor contract that puts a named engineer on your incident with a response time in writing. Those gaps are why CYBERTEC PostgreSQL Enterprise Edition (PGEE) exists. CYBERTEC develops PGEE. Worlber is the Riyadh-based database consultancy that assesses, deploys and supports it for organisations in the Kingdom.

This article is for the people who sign off on the decision: CIOs, heads of infrastructure, database leads and security teams in banking, government, healthcare, energy and telecom.

What PGEE actually is

PGEE is CYBERTEC's enterprise distribution of PostgreSQL. It stays PostgreSQL: same SQL, same ecosystem, same open-source base, with enterprise features added on top and a commercial support contract behind it. That distinction matters when you compare it with a proprietary licence, because your team is not learning a new platform. It is running a supported build of the platform it already knows.

The features that separate it from the community build fall into four groups: security, availability, performance and support. Each one maps to something an IT decision-maker already owns.

Security: controls you can show an auditor

PGEE provides encryption at every level: transparent data encryption for data at rest, encrypted client and server communication, and encryption across replication. Key management works with external key management systems, and CYBERTEC recommends keeping the key store off the database server itself, with zero-downtime key rotation.

For non-production work, PGEE adds data masking and obfuscation, so the dumps that developers and testers use do not carry live customer data. That is usually the fastest way to reduce exposure, because every test or staging copy is another system holding live customer records.

Extended auditing and security monitoring close the third gap. When an auditor asks who saw which record and when, a log you can produce from the database is a different conversation from a log you reconstruct afterwards.

Two clarifications, because this is where database marketing usually goes too far. First, CYBERTEC describes PGEE as supporting GDPR, PCI-DSS, HIPAA, CCPA and ISO requirements. Support is not the same as a guarantee, and compliance is a property of your whole system, your processes and your evidence, not of one component. Second, if your obligations come from Saudi personal data protection rules, the legal question belongs with your compliance and legal teams. What your engineers can verify is narrower and more useful: whether data stays inside your infrastructure, who can decrypt it, and whether the audit trail survives.

Availability: what five nines requires

PGEE is designed to run with Patroni, the open-source high availability framework for PostgreSQL. CYBERTEC is a major commercial contributor to that project, and the documented target for supported high availability deployments is a five nines (99.999%) uptime SLA.

Uptime at that level does not come from a licence. It comes from the shape of the cluster: an odd number of nodes, a distributed consensus store, automatic failover, a load balancer, and connection pooling in front of the database. Worlber builds these as multi-node clusters on the recommended Linux platforms (RHEL, Rocky Linux, Ubuntu, Debian), with the option to run on Kubernetes or OpenShift.

One practical note on Windows. PGEE and Patroni can be installed on Windows, but PostgreSQL integrates weakly there, and CYBERTEC's own guidance is that Linux is the platform for production. If Windows is your only option, treat it as a compromise and plan for it.

Performance: where the enterprise build shows up

Community PostgreSQL is fast, and on many workloads the difference will be small. PGEE's advantages appear in large analytical queries, especially aggregations over very large fact tables joined to small lookup tables. PGEE's query optimizer can push the aggregation down to numeric keys during the scan, so the join runs against a small aggregated result instead of millions of rows. CYBERTEC's documented figure for this pattern is around 50% faster analytics execution, with roughly double the throughput on the tested aggregation workload.

Realistic framing: this is not a blanket speed claim. It depends on the query shape. The way to find out is to run your own slow reports against both builds and compare the execution plans, which is exactly what a proof of concept should include.

Cost: what the numbers are, and what they are not

CYBERTEC's published comparisons put PGEE at up to 80% lower cost than Oracle and up to 60% lower than Microsoft SQL Server. Those figures come from a difference in licensing model: open-source distribution plus a support subscription, against per-core proprietary licensing.

Treat them as a starting point rather than a promise for your environment. Your actual saving depends on core count, which editions you run today, what third-party tooling you would have to replace, and how much of your application has to change. Get the licence model right and the direction is clear: a per-core licence is replaced by a support contract you can size to the estate you actually run.

What a migration actually involves

Worlber and CYBERTEC run migrations through a five-step method: scoping and inventory, pre-assessment to identify quick wins, detailed technical assessment with project planning, migration execution with quality assurance, and aftercare for tuning and issue resolution. Sources covered include Oracle, Microsoft SQL Server, EDB EPAS, MariaDB and MySQL, with custom work for IBM DB2, Informix and Sybase.

For Microsoft SQL Server estates there is an additional path worth knowing about. Babelfish emulates the TDS protocol that SQL Server clients speak and translates T-SQL, so applications can keep using standard SQL Server JDBC drivers while the database underneath is PostgreSQL. CYBERTEC describes a typical 40 to 70% reduction in the SQL Server estate with no application change for the parts Babelfish covers.

CYBERTEC states the limitation plainly, and you should repeat it internally: Babelfish is not 100% compatible. Workloads with heavy T-SQL stored procedure logic or SQL Server specific features may need a full migration instead. Suitability is high for development, test, staging and small databases with light T-SQL use, and low where stored procedures run the business logic.

What Worlber does in this picture

Worlber assesses whether PGEE fits the workload, plans the migration, builds and tunes the cluster, and supports it afterwards. That covers architecture and design consulting, performance tuning for large analytical workloads, migration execution with dry runs before cutover, and aftercare once the system is live. If you would rather not commit to a licence before you see evidence, start with the assessment: inventory what you run, score the complexity, and identify the quick wins.

What to check before you commit

  1. How deep does T-SQL go in your applications? A stored procedure count and a complexity scan tell you more than any compatibility claim.

  2. Which platform will run production? Linux first, and any exception documented.

  3. Where will encryption keys live? Off the database server, in a proper key management system, with a rotation plan.

  4. Which support tier matches your incident expectations? CYBERTEC's tiers differ on hours and response time, from 8x5 business hours up to 24x7, and PGEE is included at the enterprise tier.

  5. Can you produce an audit trail that survives scrutiny, and does the data stay inside your infrastructure?

  6. What does your own benchmark say? Run the real query on real data before you sign.

The takeaway

PostgreSQL is not a downgrade decision any more. For regulated workloads, the choice is between community PostgreSQL with the operational gaps your team absorbs itself, and an enterprise build with encryption, masking, auditing, high availability and a support contract attached. PGEE is the second option. CYBERTEC makes it. Worlber deploys and supports it in Saudi Arabia.

If you want to know whether it fits your workload, bring the workload. Worlber can assess the estate, run a proof of concept on your hardware or in our lab, and hand your team the execution plans to decide with. Contact Worlber to discuss whether PGEE fits your environment.