Oracle 23c's JSON Relational Duality Views: closing the gap between app developers and DBAs

 There's a tension that's existed in enterprise software for years. App developers want to work with JSON — it maps cleanly to how modern applications are built, it's flexible, and it's what most REST APIs speak natively. DBAs and architects, on the other hand, have good reasons to stick with relational models: referential integrity, normalized schemas, ACID transactions, and predictable query performance. The typical compromise involves some combination of ORMs, ETL pipelines, or storing JSON blobs in columns — none of which feels particularly clean.

Oracle 23c takes a different approach with a feature called JSON Relational Duality Views, and it's one of the more genuinely interesting things to come out of this release.

What it actually does

The idea is straightforward once you see it. A duality view sits on top of your existing relational tables and exposes their data as JSON documents — but this isn't a one-way read-only projection. Applications can read, insert, update, and delete through the view, and Oracle handles the translation back to the underlying tables automatically. The relational schema stays normalized. The application never has to know about it.

Take a common setup: a customers table and an orders table joined by a foreign key. Through a duality view, a developer sees this:

{
  "customerId": 1001,
  "name": "Jane Doe",
  "orders": [
    { "orderId": 500, "amount": 120.50 },
    { "orderId": 501, "amount": 89.90 }
  ]
}

If the application adds a new order to that document and writes it back, Oracle inserts the row into the orders table. No middleware, no custom mapping code, no sync job running in the background. The data lives in one place — the relational tables — and the JSON view is just a lens over it.

Why this matters more than it might seem

Most attempts to bridge JSON and relational data involve duplication somewhere. You either store a denormalized JSON blob alongside your normalized rows, or you maintain a separate document store and try to keep the two in sync. Both approaches create problems — extra storage, consistency issues, and complexity that compounds over time.

Duality views sidestep all of that. There's one source of truth, it lives in your relational tables, and both sides — the JSON API and the SQL layer — read from and write to the same place. Transactions are fully ACID-compliant, so there's no window where one representation is ahead of the other.

For REST API development in particular, this changes the calculus quite a bit. Building an endpoint that returns a nested JSON structure usually means writing joins, handling serialization, and sometimes maintaining a separate DTO layer. With duality views, a lot of that just goes away. The view handles the shape of the document; the application fetches and updates it directly.

What stays the same

It's worth being clear about what duality views don't change. Security and access control are still enforced at the table level, so existing privilege models carry over. Query performance still benefits from indexes on the underlying tables. And DBAs still work with the relational schema the way they always have — duality views are additive, not a replacement for anything.

In practice, this means a DBA can keep managing the database the same way, while developers get a JSON interface that actually fits how they build applications. That's a harder balance to strike than it sounds, and it's the reason this feature is worth paying attention to in 23c.

The main things I stripped out: the emoji checklists, the "best of both worlds" phrases, the "Final Thoughts" section with its broad calls to action, and anything that read like a product brochure. What's left is written more like someone who actually understands the feature and is explaining why it matters — not selling it.