PGEE vs SQL Server: where it fits, and where it does not
How PGEE compares with SQL Server on licensing, encryption, high availability and Babelfish migration, and how to judge which databases in your estate fit.
29 Sept 2026 · 4 min read
A SQL Server renewal does not care how much of your estate still matters. You pay per core, and the core count does not fall when a workload moves elsewhere or quietly stops being used.
That line item usually starts the conversation. Then comes the harder question: what would it take to run this on PostgreSQL, and what would we give up?
More than a licence change, less than a rewrite, for part of the estate. Here is what changes with PGEE, which databases suit it, and where the honest answer is to leave things alone.
PGEE is CYBERTEC's enterprise PostgreSQL product. Worlber assesses, migrates and tunes around it.
What PGEE is
PGEE keeps open source PostgreSQL as the base and adds enterprise capabilities on top: transparent data encryption, data masking, extended auditing, query optimizer work, and support with committed response times.
You are not weighing SQL Server against community PostgreSQL. You are weighing it against a supported enterprise build that keeps the Postgres base and does not license per core.
Four differences
CYBERTEC's technical comparison with SQL Server settles on four points.
| Criterion | SQL Server | PGEE |
|---|---|---|
| Encryption at rest | Enterprise edition only | Native |
| High availability | Always On availability groups | Patroni with etcd |
| Licensing | Per core | Open source plus support |
| Cost | Baseline | CYBERTEC states up to 60% savings |
The licensing row moves budgets, because per-core licensing scales with the machines you buy.
It is not free, though. Support, migration effort and operations all carry cost, and the saving lands only on the licensing line. CYBERTEC puts that saving at up to 60 percent versus MS SQL, and it depends on your edition mix, core count, workload and architecture. Test it against your own estate before it reaches a business case.
The edition line
Transparent data encryption sits behind the Enterprise edition in SQL Server. In PGEE it is native, so if you are on Standard edition and effectively buying encryption by upgrading editions, that row changes the arithmetic more than the headline cost figure does.
PGEE's documented security features also include data masking for non-production copies, extended auditing with a full event trail, and encrypted stored procedures. Masking applies to exports and to masked logical replication, so production stays visible while the copies that leave it are obfuscated. Only immutable functions are accepted as mask expressions, and volatile functions are rejected. A mask whose output changes between runs is not a mask.
The documentation positions these controls for regulated environments, with masking called out for banking, government, critical infrastructure and healthcare. Compliance is a property of how a system is configured and operated, not of a product alone, so map these capabilities against your own obligations rather than assuming a product feature closes a regulatory requirement.
Where Babelfish changes the migration
Babelfish emulates TDS, the wire protocol SQL Server clients speak, and translates T-SQL before statements reach the PostgreSQL optimizer. Applications can keep connecting through standard MS SQL JDBC drivers, which removes the largest cost and schedule risk in most migrations: application changes.
The documented path runs in three phases. Port the security foundation, including TDE and PGEE security integration. Automate deployment by putting Babelfish into a Kubernetes platform. Then move data at volume through cluster creation, dump and reload, and a connection test where the change is largely the IP address.
CYBERTEC states that 40 to 70 percent estate reduction is typical on this path, and that in 60 to 80 percent of cases no migration project is needed at all.
Where Babelfish stops
Babelfish is not full compatibility, and the documented suitability table is blunt.
| Environment | Suitability |
|---|---|
| Development, test and staging | High |
| Small databases, low T-SQL usage | High |
| Heavy T-SQL stored procedures | Medium to low |
| Extensive SQL Server specific features | Low, may need a full migration |
Read that before committing a roadmap. If your estate leans hard on SQL Server specific behaviour, the compatibility path is a staging ground rather than a destination, and the destination costs what a real port costs. A migration that quietly becomes a rewrite is not a saving. It is the same spend, arriving later.
What Worlber does
PGEE is CYBERTEC's product. Worlber's role is the work around it, and the assessment comes first.
That assessment follows five steps: scoping with a database inventory, pre-assessment to categorise workloads and find quick wins, a detailed technical assessment, migration execution, and aftercare. Aftercare is the step teams skip, and it decides whether a licensing saving survives contact with production.
Worlber's migration services cover Oracle, MS SQL Server, EDB EPAS, MariaDB, MySQL and MongoDB, with custom work for DB2, Informix and Sybase. Execution includes dry runs before production cutover, which turns the suitability table into evidence.
The part worth remembering
This is not a question about which database is better. Blanket superiority claims do not survive scrutiny in either direction. It is a question about which workloads fit a different licensing model and a different compatibility surface.
The licensing argument is the easy part. The suitability table is the hard part.
*Cost and estate reduction figures are CYBERTEC's published positioning, not Worlber measurements.*
Bring us your SQL Server inventory
Send your core count, edition mix and the databases you would consider moving first. Worlber will tell you which ones fit PGEE and which ones should stay where they are. If most of your estate should stay on SQL Server, we will say that too.