OracleDB

Oracle Database is a commercial relational database with a long institutional history. Technically it is capable and mature: sophisticated query optimisation, partitioning, clustering through RAC, and operational tooling developed over decades of large deployments.

The reason it appears in this garden is not that I would choose it. It is that in institutional settings it is frequently already there, and integrating with it is the problem rather than selecting it.

What it does well

Where it genuinely earns its place is at scale under transactional load with strict availability requirements — large multi-tenant systems, financial workloads, anything where the operational tooling and vendor support are load-bearing. PL/SQL is a substantial procedural language, and a great deal of institutional business logic lives in it.

Where the cost is

Licensing shapes decisions in ways the feature list does not suggest. Costs are per-core with edition-dependent multipliers, which means adding CPUs to an application server can have licence implications, and architectural choices that would be routine elsewhere — horizontal scaling, spinning up test environments, running a full-size staging copy — acquire a price. I have seen the licence model constrain designs more than any technical limitation of the database.

The practical consequence for development is that developers often cannot have a local instance matching production, so the project-local database pattern that works well with PostgreSQL does not transfer. Testing against a different database than you deploy on is a real source of late surprises.

Choosing against it

For new work I would use PostgreSQL without much hesitation. It has closed most of the technical gap, has better extension support for the geospatial and scientific work I do — PostGIS in particular has no comparable Oracle equivalent for my purposes — and imposes no licence constraints on architecture.

The honest caveat is that migrating away is expensive in proportion to how much logic lives in PL/SQL, which in a long-lived institutional system is usually a great deal. “Use Postgres instead” is sound advice for a new system and not very useful for an existing one.

An ORM abstracts enough of the difference for straightforward CRUD work and stops helping precisely where Oracle-specific features are being used, which is generally why it was chosen.

See also: PostgreSQL, MySQL, ORMs, and SQLite for the other end of the spectrum.