I have lost count of how many times I have read that PL/SQL is dead. The first time was probably around 2014, when somebody on Hacker News explained that all logic belongs in the application layer. Then came the microservices wave. Then Spark. Then dbt. Then the lakehouse people. Then a brief moment where someone tried to convince an insurance CFO that statutory reserves could be calculated in a Python notebook orchestrated by Airflow.
Meanwhile, the actual systems producing the numbers that regulators read every quarter are still, overwhelmingly, packages of PL/SQL running inside an Oracle database that has been patched since 2011. This is not because banks and insurers are stupid or slow. It is because nobody pitching the replacement has bothered to understand what PL/SQL is actually doing for them.
What PL/SQL actually replaces
When a junior engineer looks at a 4,000-line package body computing IFRS 17 CSM movements or BDDK regulatory ratios, they see legacy. What they are actually looking at is the combination of:
- A transactional execution engine with serializable isolation
- A type system tightly coupled to the storage layer
- A deterministic, single-process runtime where ordering is guaranteed
- An audit surface where every DML is traceable to a session, a user, and a timestamp
- A deployment model where the code lives next to the data it mutates
Replacing PL/SQL is not replacing a language. It is replacing all five of those properties simultaneously. Most modern stacks replace one and quietly drop the other four on the floor.
The statutory reporting problem nobody wants to talk about
In Turkish insurance, the monthly Hazine reporting cycle is unforgiving. The numbers you submit are the numbers you defend. If the technical provisions in your AKS submission do not reconcile to the general ledger, you do not get to explain that your Spark job had a stragglers problem and the shuffle partitioned weirdly. You get a finding.
The operational requirements are concrete:
- Reproducibility down to the kuruş, three years later, on demand
- The ability to re-run a single policy's reserve calculation in isolation and get the exact same result
- An auditable change history of every line of logic that touched a regulated figure
- Closure of the reporting period inside a transactional boundary that cannot leak partially-computed state
A PL/SQL package committed to a database with a proper change management process gives you all of this almost for free. A modern data stack gives you a Git repository, a CI pipeline, six YAML files, a feature store, a lineage tool that mostly works, and a 40-page runbook explaining how to recover when the orchestrator double-fires a task.
The performance argument is backwards
The standard pitch against PL/SQL is that it does not scale horizontally. This is true and almost always irrelevant. Statutory reporting workloads are not web-scale. A mid-sized Turkish insurer is processing somewhere between five and fifty million policy-records per cycle. That fits comfortably in a single Exadata node's buffer cache.
What actually matters at that scale is data locality. Every time you move a row from the database to an external compute engine, serialize it, deserialize it, process it, and write it back, you are paying for a network hop that PL/SQL does not pay. For row-by-row actuarial logic with heavy joins against reference tables, set-based SQL inside the database wins by an order of magnitude against any external runtime. I have benchmarked this against PySpark on the same hardware budget more than once. It is not close.
Where PL/SQL genuinely deserves to lose
I am not arguing PL/SQL belongs everywhere. It is a terrible choice for:
- Anything user-facing or latency-sensitive in the millisecond range
- ML model training and most ML inference
- Event-driven workloads that need to fan out to dozens of consumers
- Anything where the team writing it does not actually know SQL
That last point is doing more damage than any architectural argument. The reason PL/SQL codebases rot is not that PL/SQL is bad. It is that the cohort of engineers who can write disciplined, package-scoped, properly-instrumented PL/SQL is shrinking, and the people inheriting these systems are being told by their tech leads that learning it is a career dead-end. So they wrap it in views, build a parallel pipeline in Python that recomputes 80% of it, and now you have two sources of truth and twice the bugs.
What modern tooling would actually need to earn the replacement
If someone wants to seriously displace PL/SQL from statutory reporting, the bar is not features. It is operational properties. The replacement needs to provide:
- Transactional semantics across the entire pipeline, not just per-task
- Deterministic execution under retry, including identical floating-point behavior
- A single, queryable history of every code version that produced a reported figure
- Sub-second restart of a single failed calculation without re-running the batch
- A security model the regulator's auditor can understand in one meeting
Delta Lake plus dbt plus Airflow plus a lineage tool gets you maybe two of these on a good day, and the integration tax is paid by your on-call rotation. Snowflake's procedural extensions and BigQuery's stored procedures are closer, but they are PL/SQL with a different syntax and worse tooling. The honest reading is that the industry has spent fifteen years reinventing what PL/SQL already does, badly, and calling it progress.
The 2026 reality
The banks and insurers I work with are not going to rip out their PL/SQL in 2026. They are not going to do it in 2030 either. What they are going to do, and what the smart ones are already doing, is treat PL/SQL as a first-class engineering discipline again: version-controlled properly, code-reviewed seriously, instrumented with the same rigor as application code, and staffed with engineers who are paid like the senior infrastructure people they actually are.
The declaration that PL/SQL is dead is mostly a tell. It tells you the person making it has never been the one signing off on a regulatory submission. The systems that cannot fail are not running on the language that is fashionable. They are running on the language that works.