EDB and the art of leaving Oracle.

In 2014, an Ericsson team had a problem measured in television titles. Its content management system needed to process more of them. The old database could not keep pace. Adding capacity would bring higher licensing and maintenance costs. Yet replacing it threatened something harder to price: the applications and knowledge accumulated around it.

The team considered NoSQL and document databases. Those alternatives came with application refactoring. EDB Postgres offered compatibility with the existing system and let people retain familiar skills and tools. In the published case, ingestion rose from five titles per minute to eleven.

That small operational detail explains a company whose current vocabulary includes sovereign AI, agent runtimes and converged analytics. EDB understands an awkward fact about enterprise technology: the better established a system becomes, the more things have to agree before anyone can replace it.

The expensive part is leaving

A database contains records. A database installation also contains assumptions. Applications expect particular SQL behavior. Stored procedures encode business rules. Administrators know which diagnostics to trust. A cheaper engine has to make financial sense after those dependencies enter the calculation.

EnterpriseDB began in 2004 with enterprise Postgres as an alternative to Oracle. Its compatibility offering, long known as EDB Postgres Advanced Server, supports Oracle-style data types, SQL and procedural logic. The documentation describes functions, triggers, packages and client interfaces. These are the joints where a migration can become expensive.

Compatibility is a matter of degree. The sensible buyer tests the procedures that matter, including their strange edge cases. EDB’s appeal is that a move to Postgres can preserve more of the application investment. Whether it does so is a workload question.

The engineers behind the escape hatch

EDB is a commercial company built around a database it does not own. PostgreSQL is an independent open-source project. Anyone can use it under its permissive license. That arrangement gives EDB both an opportunity and a permanent competitor: the community software itself.

Its answer includes engineering expertise. EDB employs PostgreSQL contributors and supports tools such as pgAdmin and Barman. In September 2020, it acquired 2ndQuadrant, bringing another group of Postgres specialists into the business. For a customer facing a difficult database problem, proximity to the people who understand the internals has practical value.

There is a useful feedback loop here. Supporting enterprise workloads exposes engineers to awkward production problems; improving the shared database can benefit users beyond the paying customer. EDB’s commercial judgment rests partly on making that shared foundation more useful.

Free software. Paid responsibility.

The business model becomes clear when someone has to answer the late-night call. EDB sells software subscriptions, support, managed cloud services and professional help. Its plan families cover open-source support, enterprise Postgres, analytics and distributed high availability. Production support runs around the clock; development support has different terms.

The bill also includes the work around the subscription: infrastructure, migration, testing, training and ongoing operations. A license comparison alone misses much of the decision. Buyers need to know what capacity they are licensing, which capabilities they need and who owns each operational task.

EDB reports more than 1,700 customer organizations. Its public stories include banks, trading infrastructure and retailers. These buyers have reasons to value deployment choice: a public cloud may fit one workload while a customer-controlled data center fits another. IBM, Red Hat, NVIDIA and Supermicro partnerships address different parts of that infrastructure.

The alternatives are substantial. A capable team can run community PostgreSQL. Cloud providers offer managed databases. Oracle remains an option for organizations whose applications depend heavily on it. EDB’s competitive case is strongest when compatibility, specialist support and control over deployment matter together.

Now the intelligence comes to the data

The newer EDB Postgres AI platform extends the argument. Alongside transactions, it addresses analytics and AI. The company’s pitch is that enterprises should be able to use their data without first surrendering control of where it runs or how it is accessed.

In June 2026, EDB announced agentic database capabilities and converged analytics. Its automated operations allow customers to choose which actions run autonomously, which need approval and which wait for maintenance. Governance becomes an operational setting, with an audit trail attached.

“choose a path that gives you maximum independence with minimum risk”

Grigoriy Zeleniy, CTO, Euronext FX

For a bank, that distinction matters before any model produces an answer. An agent that can reach sensitive records needs the right permissions at the moment it acts. Putting those controls near the records is EDB’s architectural argument; it does not relieve the customer of deciding which actions should be allowed.

The expansion still has to satisfy ordinary database requirements. In August, EDB added disaster recovery for WarehousePG. It reported one banking deployment where restore-point replay averaged sixteen minutes against a previous recovery process taking nearly two days. Those figures describe one environment. The broader point is familiar: analytics becomes infrastructure when the business cannot wait for it to return.

Start with the thing you cannot break

For someone evaluating EDB, the useful first move is a rehearsal. Take a representative application, inventory its dependencies, test its troublesome procedures and restore a backup. Measure performance under the expected load. Put a rollback plan beside the migration plan. These are ways to turn a platform pitch into an operating decision. They also make the purchasing conversation more useful: an availability target needs an architecture behind it, and a support promise needs a clear division of responsibilities.

If an essential dependency cannot move, or rewriting costs consume the savings, the migration case weakens. A small application with an experienced Postgres team may need little of EDB’s commercial machinery. The product earns its place through the work it removes and the responsibility it can credibly accept.

Ericsson’s team began with content arriving too slowly. EDB’s present-day customers may begin with an AI project or a warehouse recovery problem. The useful question is still concrete: which part of this system can change, while everything people depend on keeps working?