Published: 2026-05-13

JSON in Relational Databases: 5 Engines Compared (2026)

The relational vs document debate looked settled a decade ago. It is not settled anymore. MongoDB's licensing change in 2018 (SSPL) pushed a wave of teams to reconsider, and every major relational database spent the years since adding native binary JSON types, path indexes, and standards-track SQL/JSON functions. As of May 2026, every major relational engine has either a native binary JSON type or a stable text-plus-helpers story, so the question is no longer "can my SQL database do documents?" but "which one does it best for my workload?" Jam SQL Studio works across all five engines below, and this is the side-by-side reference we wish existed when we started building JSON column support. The on-disk format that everything else builds on is still the RFC 8259 grammar — engines differ on how they store, parse, and index it, not on what they accept.

Quick Answers

Short factual answers to the questions that bring people to this page. The detail lives in the matrix and per-engine sections below.

Q: Which relational database has the best JSON support?

A: PostgreSQL has the most complete JSON stack: the binary jsonb type since 9.4 (2014), GIN indexes on the whole document, the SQL/JSON path language since 12, and the standard JSON_TABLE, JSON_VALUE, JSON_QUERY, and JSON_EXISTS functions since 17. Oracle is the closest competitor and is the only relational engine that ships a MongoDB-wire-compatible API (23ai / 26ai).

Q: Can a relational database replace MongoDB in 2026?

A: For document workloads under a few terabytes that fit on a single primary, yes. Every major relational engine now stores documents in a native or de-facto binary JSON format, supports JSONPath queries, indexes JSON paths, and enforces multi-document ACID transactions. MongoDB still wins for sharded multi-region writes, the aggregation-pipeline mental model, and document-native operational tooling.

Q: Which databases have a native binary JSON type?

A: PostgreSQL (jsonb, since 9.4 in 2014), MySQL (JSON, since 5.7 in 2015), Oracle (native JSON / OSON, since 21c in 2021), Azure SQL Database and Azure SQL Managed Instance (json, GA), and SQL Server 2025 (json, in preview). SQLite stores JSON as TEXT but added a JSONB binary BLOB representation in 3.45 (2024). On-prem SQL Server 2016–2022 still uses NVARCHAR(MAX) with an ISJSON CHECK constraint.

Q: How does JSON indexing differ across SQL engines?

A: PostgreSQL is the only engine with a true whole-document index — GIN over jsonb covers ad-hoc path and containment queries. Oracle has the closest equivalent with JSON Search indexes plus function-based and multi-value indexes. MySQL relies on functional indexes and multi-valued indexes for array paths (8.0.17+). SQL Server and SQLite both use the generated/computed-column-plus-B-tree pattern for known paths.

Q: Is JSONB better than JSON in PostgreSQL?

A: For almost every production use case, yes. jsonb stores documents as a parsed binary tree, supports indexing with GIN, and skips re-parsing on every read. The text json type only makes sense when byte-for-byte preservation of an externally-signed document is required.

Why This Comparison Matters in 2026

Three things changed at once. MongoDB's switch to the SSPL turned every managed-service provider into either an Atlas customer or a fork, and pushed self-hosted users to look harder at what their existing database could already do. PostgreSQL 17 (2024) closed the last big gap in standards compliance by shipping JSON_TABLE, JSON_VALUE, JSON_QUERY, and JSON_EXISTS. And Oracle 23ai added a wire-compatible MongoDB API, letting existing MongoDB drivers connect to Oracle without code changes — the strongest signal yet that the document/relational split is collapsing.

The practical effect: an engineer choosing where to put a products, events, or audit_log document column today has five credible relational options, each with subtly different trade-offs. This guide compares them on the dimensions that actually affect production code — storage, validation, path operators, indexing, transactions, and the path to (or away from) MongoDB.

Master Comparison Matrix

Every fact below is taken from the engine-specific guide it links to. Where a row says "preview" or "GA on Azure", the qualifier is load-bearing — on-prem behaviour differs.

Per-Engine Verdict

PostgreSQL

PostgreSQL has the most complete JSON stack in the open-source world. jsonb stores documents as a binary tree, GIN gives you a true whole-document index for ad-hoc queries, the SQL/JSON path language has been there since 12 (2019), and PostgreSQL 17 closed the remaining standards gap with JSON_TABLE, JSON_VALUE, JSON_QUERY, and JSON_EXISTS. If your only constraint is "best JSON in a relational engine", this is the default answer. See the deep dive in PostgreSQL JSON & JSONB.

MySQL

MySQL was the first widely-deployed relational engine to ship a real binary JSON type, all the way back in 5.7 (2015). 8.0 added JSON_TABLE (8.0.4), functional indexes (8.0.13), multi-valued indexes for array paths (8.0.17), and JSON_VALUE (8.0.21). There is no GIN-equivalent whole-document index, but multi-valued indexes are the right answer for most "find documents where tag = X" queries. Pragmatic, fast, and well understood. See MySQL JSON Columns.

SQL Server

SQL Server's JSON story is bifurcated. From 2016 to 2022, JSON lived in NVARCHAR(MAX) columns with an optional ISJSON CHECK constraint and helper functions like JSON_VALUE, OPENJSON, and JSON_MODIFY. As of May 2026, the native json type is GA on Azure SQL Database and Azure SQL Managed Instance, and remains in preview on SQL Server 2025 (17.x) for on-premises deployments — teams targeting the box product should plan for the preview-to-GA window before standardising on it. The persisted-computed-column-plus-B-tree pattern remains the universal indexing recipe. Full details in SQL Server JSON Support.

Oracle

Oracle has invested in JSON longer than most teams realise — JSON_VALUE shipped in 12c (2014), JSON_TABLE in 12.2, the native JSON type with OSON binary storage in 21c (2021), and 23ai adds JSON Relational Duality, JSON Schema validation, and the Oracle Database API for MongoDB — the only relational engine that lets existing MongoDB drivers connect directly. As of May 2026, 26ai is the current Oracle GA release line, consolidating the 23ai feature set under the AI Database name. If you run Oracle and want to deprecate a MongoDB cluster, the path is short. See Oracle JSON Support.

SQLite

SQLite ships the json1 extension built in and enabled by default since 3.38 (2022). There is no formal JSON type — documents live in TEXT — but the operator and function vocabulary borrows directly from PostgreSQL and MySQL, and 3.45 (2024) added a JSONB binary BLOB format that skips re-parsing on every read. For embedded, edge, and single-server document workloads, SQLite plus json1 handles what used to require running MongoDB next to your application. See SQLite JSON Support.

Do You Still Need MongoDB?

For most teams the honest answer is no, with a caveat. The relational engines have closed the document-store gap so completely on storage, validation, querying, and indexing that the question now turns on operational shape rather than feature parity. A single PostgreSQL or MySQL primary holding a few hundred GB of documents will outperform an underprovisioned three-node MongoDB cluster on real query workloads while costing less to operate, because there's one engine to monitor instead of two.

MongoDB still has real strengths. Sharded multi-region writes are first-class instead of bolted on. The aggregation pipeline is a different mental model that some teams genuinely prefer over chained CTEs. Operational tooling — Atlas, MongoDB Compass, Charts — was designed for documents from day one rather than retrofitted onto a row store. And BSON's binary types (ObjectId, Decimal128, native Date) are nicer to work with than JSON-encoded text equivalents.

The decision then is less about features and more about workload shape. The split that ages well:

The "we'll need MongoDB later for scale" decision is usually paid for in immediate operational complexity and almost never recouped — in the meantime, every SELECT that joins documents to relational data is harder than it needs to be.

Browse JSON Columns Across All 5 Engines

JSON columns are notoriously painful in most SQL IDEs — they render as a single line of escaped text, you can't filter by path without typing JSON_VALUE / json_extract / ->> by hand, and there's no way to peek at the document shape without writing a query. Jam SQL Studio treats JSON as first-class on every engine in this guide: cells render as collapsible trees, the filter chip exposes path-aware sub-operators (has property, property =, property contains) that compile to the engine-correct operator under the hood, and a Peek popover scans the loaded rows to show every JSON path with its prevalence — the same schema-discovery experience MongoDB Compass made famous, applied uniformly to jsonb on Postgres, JSON on MySQL, native json or NVARCHAR(MAX) on SQL Server, native JSON or CLOB-with-IS JSON on Oracle, and TEXT or JSONB on SQLite. One mental model regardless of engine.

Last verified against postgresql.org, dev.mysql.com, learn.microsoft.com, docs.oracle.com, and sqlite.org on 2026-05-13.