Comparing Today's Multi-Model Databases

Multi-model databases sound simple on paper.

One database, many data models, less architecture sprawl.

That is the pitch.

The reality is less neat.

Once you look closely, "multi-model" can mean very different things. Sometimes it means one engine with several models that actually work together. Sometimes it means one database plus a growing pile of attached capabilities. Sometimes it means multiple APIs over one cloud platform. Sometimes it means a strong idea that still has rough execution.

So if you are evaluating the current landscape, the label alone is not enough.

You need to ask harder questions.

• How native is the multi-model support?

• Does the database feel coherent, or just broad?

• Does it stay pleasant once the workload becomes real?

• Are you buying a database, or a stack of compromises with a friendly landing page?

This post is my attempt to compare some of the most prominent multi-model options people talk about today:

• PostgreSQL + extensions

• SurrealDB

• Couchbase

• ArangoDB

• OrientDB

• ArcadeDB

For context, this is not a benchmark post.

The ratings here are closer to review scores than benchmark numbers. They are editorial judgments about architecture, feature depth, workflow quality, operational shape, and how convincing each database feels as a serious multi-model system today.

The real fault lines

Most comparison posts flatten all of these databases into one category and then act surprised when the tradeoffs look inconsistent.

They are inconsistent because these systems are solving different versions of the problem.

There are at least five distinct approaches hiding under the same "multi-model" label:

• Extension-driven breadth: PostgreSQL + extensions

• Native engine multi-model: ArangoDB, OrientDB, ArcadeDB

• Document-first platform expansion: Couchbase

• Modern unified developer story: SurrealDB

• API / platform interpretation: Cosmos DB and similar systems

I do not think all five belong in the same category in the strict database sense, even if vendors market them that way.

If you do not separate those approaches, the category stops making sense.

That is also why direct one-line comparisons are often misleading. A database can score lower on native support and still be the safer production choice. Another can score higher on native support and still be the riskier operational bet.

How I am judging them

Each database gets rated on the same seven dimensions:

• Native multi-model support

• Multi-model depth

• Performance potential

• Developer experience

• Operational simplicity

• Ecosystem / maturity

• Production confidence

The first category matters most.

I am not asking whether a database can be stretched into several roles. Many can. I am asking whether multiple models are part of the actual design, or whether the user is doing the integration work by hand.

Native multi-model support and multi-model depth are not the same thing.

A database can be very native and still be shallow. That usually means the models are built into the product and query language, but the actual implementations still feel lighter than specialized systems.

A database can also be less native and still be deep. PostgreSQL is the clearest example: many of its strongest non-relational capabilities come from extensions, but some of those extensions are still serious pieces of engineering.

For this article, a higher nativeness score means the user pays less integration penalty when new models show up.

If you need to add a separate external database just to get one more model, that should hurt the score a lot.

If you can stay inside the same database but need an extension, that is still a penalty, but a smaller one.

If the model is already part of the same core engine or the same native database story, that should score much better.

So nativeness here is not just about marketing language. It is about how much stack stitching the user still has to do when requirements expand.

The other categories matter because the category has a bad habit of hiding tradeoffs behind a neat label. A database can look impressive in a product diagram and still feel second-class once real workloads arrive.

PostgreSQL + extensions

PostgreSQL is not a native multi-model database in the strict sense.

Supported models:

Model Support Notes

Relational Native Core identity and strongest model.

Document / JSON Native Via json / jsonb, but still within PostgreSQL’s relational engine.

Spatial Extension Usually via PostGIS; powerful, but not part of the core engine identity.

Time-series Extension Usually via TimescaleDB; serious in practice, but not core-native PostgreSQL.

Vector Extension Usually via pgvector; practical, but still extension-led.

Graph Extension / Application-level Usually via Apache AGE or application-side modeling, not core-native graph semantics.

It is still the practical benchmark that every serious multi-model system ends up being measured against.

Why? Because PostgreSQL keeps absorbing more territory.

Relational data is its home ground. JSON and jsonb made document-style usage normal. PostGIS covers geospatial workloads. TimescaleDB pushed hard into time-series. pgvector made vector search part of the conversation for mainstream teams. There are also graph-style options like Apache AGE if you want to keep pushing further.

That is a remarkable amount of coverage.

The problem is that coverage is not the same as coherence.

PostgreSQL + extensions is powerful, but the integration burden shifts toward the user. You decide which extension owns which problem. You learn the quirks, upgrade risks, operational differences, and uneven ergonomics between those pieces. The core database is stable. The workload-specific stack becomes your responsibility.

That is the PostgreSQL tradeoff in one sentence: Best-in-class practical confidence, weaker multi-model integrity.

Category Score Why

Native multi-model support 4/10 It is not truly native multi-model. Even when extensions keep you inside the same database, the user still pays a large stitching and compatibility penalty.

Multi-model depth 7/10 The feature depth can be excellent, but it is uneven and fragmented by extension boundaries.

Performance potential 8/10 PostgreSQL is a serious engine, and some extensions are very strong, but cross-model optimization is not one coherent story.

Developer experience 8/10 SQL, tools, docs, and ecosystem are excellent, though the experience becomes rougher as extensions pile up.

Operational simplicity 4/10 Running PostgreSQL is easy by industry standards. Running a stitched stack of extensions across many projects is not.

Ecosystem / maturity 10/10 Nobody in this list beats PostgreSQL here.

Production confidence 10/10 If you want the safest broad platform, this is still the default answer.

Trust review:

extremely high, but only if you accept that you are trusting a platform plus an integration strategy, not one native multi-model engine.

Query model:

PostgreSQL’s center is still SQL. JSON support is strong, jsonb has serious operator support, and GIN indexing makes document-style querying practical. But every added model brings its own syntax, extension behavior, and planning assumptions. There is no single multi-model query language tying the whole thing together.

Engine / storage shape:

This is still one of the strongest storage and execution engines in the industry, but the important part is where the extra models live. jsonb stays inside PostgreSQL. PostGIS, TimescaleDB, pgvector, and graph-oriented options live in different layers around that core. The engine is first-class. The multi-model story is distributed across extensions.

How native is the multi-model claim?

Only partially native. PostgreSQL can absolutely play multi-model in real production systems, but it does that through a strong core plus specialized additions, not through one database designed from day one around equally native relational, graph, vector, and time-series semantics.

Where it feels first-class:

• Relational workloads

• Operational SQL

• Mature production tooling

• Extension-backed specialization when the team knows exactly what it is doing

Where it feels second-class:

• Cross-model coherence

• Unified multi-model query experience

• Workloads that force several extensions to behave like one native system

Best fit:

• Teams that want the safest broad platform

• Companies with strong PostgreSQL expertise

• Workloads where extension sprawl is still manageable

Poor fit:

• Teams that want one native multi-model system instead of a strong core plus many additions

Short verdict:

The safest powerful option, and still the practical benchmark, but the user pays for multi-model breadth with growing integration debt.

SurrealDB

SurrealDB has one of the strongest product visions in this space.

Supported models:

Model Support Notes

Document Native but shallow SurrealDB itself describes the system as being, at its core, document-oriented.

Graph / relations Native but shallow Relations and traversal are real, but this still does not look like a deep graph-tooling database.

Key-value style access Backed by KV storage layer The engine runs over KV backends such as RocksDB, SurrealKV, TiKV, and browser IndexedDB. This is more a storage foundation than a separate first-class model.

Vector Native but shallow Present in the product, but not obviously a deep specialized vector engine.

Time-series Native but shallow Present in the product, but their own docs admit specialized TSDBs currently do retention and compression better.

Full-text / search Native direction Present, but not a deep search-first system.

It understands the modern developer instinct very well: fewer hops, one system, SQL-like querying, document and graph ideas in one place, and a cleaner story than bolting together half a dozen tools. That is why it gets attention so quickly.

The problem is not coverage. SurrealDB covers a lot.

The problem is depth.

Too many of its models still feel like lighter versions of the real thing. Graph is present, but not as a rich graph-tooling environment. Time-series is present, but not like a serious analytics-grade TSDB. Vector is present, but not in a way that makes it look like a best-in-class vector engine.

The architectural reason matters here. Much of the multi-model story is being pushed through one generalized KV-backed foundation. And because that foundation can itself sit on top of other KV engines, many models end up feeling like interpretations over the same storage pattern rather than deeply specialized implementations. The product surface is broad. The engine-level realization is still shallow.

Category Score Why

Native multi-model support 9/10 Multi-model is deeply part of the core product and engine identity, not just an add-on.

Multi-model depth 3/10 Broad and ambitious, but too many models feel much lighter than the real specialized versions they resemble.

Performance potential 6/10 Good enough to be interesting, but I still see more promise than proof.

Developer experience 8/10 Strong product storytelling, approachable model, modern appeal.

Operational simplicity 6/10 Simpler than managing a stitched stack, but simplicity in concept is not the same as maturity in production.

Ecosystem / maturity 5/10 Still young compared with the more established systems here.

Production confidence 4/10 I would watch it closely, but I would still treat it as a bet rather than a settled answer.

Trust review:

Medium. Easy to understand, easy to want, still much harder to trust deeply than the product story suggests.

Query model:

SurrealQL is one of SurrealDB’s real strengths. It gives the database a strong unified surface and makes the system feel coherent much earlier than many other multi-model products.

Engine / storage shape:

SurrealDB presents itself as one native multi-model database rather than a database plus extensions. That part is fair. But once you look at the architecture docs, the system is clearly layered over a key-value backend story. That does not make it fake. It does explain the shallowness. The “many models” claim is being realized through one broader document/KV-oriented engine shape, sometimes itself sitting on top of another KV engine, rather than through several equally deep model-specific engines.

How native is the multi-model claim?

More native than PostgreSQL + extensions or Couchbase’s service-style expansion, but still not equally convincing across every claimed model. The claim is structurally native at the product and query layer. At the engine layer, it still feels more like one broader KV-backed system interpreting many models than several deeply realized model-specific implementations.

Where it feels first-class:

• Product vision

• Modern developer appeal

• Unified story around documents, relations, and fewer system hops

Where it feels second-class:

• Hard production confidence

• Deep capability maturity across every advertised area

• Trust under heavier or less forgiving workloads

• Several models feeling lighter than their specialized counterparts

Best fit:

• Teams willing to bet on direction

• Builders who care a lot about developer-facing coherence

• Projects where the vision aligns closely with the workload

Poor fit:

• Conservative production environments that need long-proven operational confidence

Short verdict:

One of the strongest visions in the category, but still too broad and too light in too many places to count as one of the most convincing finished implementations.

Couchbase

Couchbase sits in an interesting middle ground.

Supported models:

Model Support Notes

Document Native core Main center of gravity.

Key-value Native core Part of the core operational model.

Query over JSON documents Native query layer Via SQL++; not a separate model so much as a strong query surface over document data.

Full-text search Platform service Official part of the platform, but not an equal core data model.

Analytics Platform service Official part of the platform, but not an equal core data model.

Eventing Platform service Official part of the platform, but not an equal core data model.

Mobile sync / edge sync Platform service Official part of the platform, but not an equal core data model.

Graph Not core native Not a real native graph database identity.

It is not usually the first database people name in multi-model debates, but it has quietly built a broader platform than many people realize. Document data is still the center, but key-value access, SQL++ querying, full-text search, analytics, eventing, and mobile sync make it much more than "just a document database."

That broader platform story is real.

So is its production credibility.

Couchbase has been around, it has enterprise weight, and it knows how to solve operationally serious problems. If you care about distributed document-heavy workloads with search, analytics, eventing, and mobile sync, it has more depth than a lot of trendier names.

But it still does not feel like the cleanest native multi-model database in the stricter sense.

It feels more like a strong document-first platform that expanded intelligently around its center of gravity, with multiple surrounding services rather than multiple equal native models.

That is why I would place it closer to Cosmos DB than to ArangoDB in category shape, even though it is still stronger than Cosmos DB at the database-core level. Couchbase has a real native database center. The broader multi-model feeling comes from the platform built around that center, not from one engine where every model is equally native.

Category Score Why

Native multi-model support 4/10 Broader than a simple document store, but the surrounding services still mean the user is assembling a platform rather than getting one truly native equal-model engine.

Multi-model depth 5/10 Real depth in document-heavy environments plus strong surrounding services, but still not equal native depth across several first-class models.

Performance potential 8/10 Strong distributed performance profile in the workloads it targets.

Developer experience 7/10 Solid, especially if you buy into SQL++ and the surrounding platform.

Operational simplicity 7/10 Much cleaner than stitching many systems yourself, though still a substantial platform to run well.

Ecosystem / maturity 9/10 Mature, enterprise-known, operationally serious.

Production confidence 8/10 Strong for teams whose needs align with its shape, even if it is not the cleanest true multi-model engine.

Trust review:

High in its zone. Less compelling as a general answer to every multi-model ambition.

Query model:

Couchbase has a clearer center than many people expect. SQL++ gives it a SQL-like way to query JSON documents, and that matters. But the broader platform also depends on distinct services like Search, Analytics, and Eventing. That means the user experience is broader than a plain document store, while still not feeling like one single multi-model language across equal models.

Engine / storage shape:

Couchbase feels like a distributed document database that grew outward into a platform. That platform is substantial: query, search, analytics, eventing, and mobile sync are all real capabilities. But they are also separate services with their own architecture, which is why the system feels platform-first more than engine-pure.

How native is the multi-model claim?

Moderately native in the sense that the capabilities are part of the official platform, not random side tools. But it is still not native in the stricter sense of one engine equally expressing multiple models as first-class peers. It is closer to a document-first database plus first-party services than to a truly native multi-model engine.

Where it feels first-class:

• Document-heavy applications

• Mobile sync and edge-aware scenarios

• Distributed operational deployments with a strong platform wrapper

Where it feels second-class:

• Native multi-model purity

• Graph-first or deeply unified model semantics

• "one engine, many truly equal models" expectations

Best fit:

• Teams centered on document workloads that also need search, analytics, events, and sync

• Organizations that want a mature platform more than a category-pure database design

Poor fit:

• Teams specifically looking for a graph-document-key-value engine designed as one native core from the beginning

Short verdict:

More substantial than hype-driven newcomers, especially for document-heavy and sync-aware systems, but closer to a document-first platform than to a truly native multi-model engine.

ArangoDB

ArangoDB is one of the clearest examples of a native multi-model database.

Supported models:

Model Support Notes

Document Native First-class part of the core design.

Graph Native First-class part of the core design.

Key-value Native Expressed through the same overall engine story.

Full-text search Native Via ArangoSearch, natively integrated into the database.

Vector Native, newer Officially supported, but still newer than the older document/graph/key-value core.

Time-series Not core native model Not a real native time-series identity in the way ArcadeDB, NodeDB, or SurrealDB claim it.

Its core story has been consistent for a long time: document, graph, and key-value in one engine, with one query language and a relatively coherent mental model.

That coherence is its real strength.

ArangoDB does not feel like a database that accidentally became multi-model. It feels designed around that identity. And unlike some younger systems, it has had enough time in the market to turn that identity into something operationally credible.

Its biggest advantage is discipline.

AQL gives it a strong center. The system is not pretending to be every data product at once. That restraint makes it feel more trustworthy than several flashier databases in this category.

Category Score Why

Native multi-model support 7/10 Clearly native and coherent, but with a narrower native model spread than the strongest broader true multi-model systems.

Multi-model depth 6/10 Document, graph, key-value, search, and newer vector support give it real strength, but not the same broader all-model depth as the strongest true multi-model engines.

Performance potential 8/10 Strong enough to take seriously, without feeling like a toy unifier.

Developer experience 8/10 Coherent query model, coherent mental model, less fragmentation than extension-led systems.

Operational simplicity 6/10 Reasonable, though not trivial.

Ecosystem / maturity 8/10 Mature enough to be credible without having PostgreSQL-scale gravity.

Production confidence 8/10 One of the stronger native multi-model bets.

Trust review:

High. Not because it promises the most, but because it promises a coherent set of things and mostly behaves like it means it.

Query model:

ArangoDB benefits enormously from AQL. That one choice gives it much of its credibility. AQL is not just a convenience layer. It is the reason document, graph, key-value, search, and newer vector support still feel closer to one database than to a bundle of unrelated capabilities.

Engine / storage shape:

ArangoDB is explicit about being a native multi-model database, and its storage engine story supports that claim better than many competitors. Its current storage engine is based on RocksDB, but that does not reduce it to an API wrapper over someone else’s database. The important point is that the engine and query model were designed around document, graph, key-value, search, and now vector support working together as one product.

How native is the multi-model claim?

Very strong. This is one of the clearest cases where the label matches the design, not just the marketing.

Where it feels first-class:

• Native document + graph + key-value integration

• Coherent query experience

• Teams that value discipline over hype

Where it feels second-class:

• Newer categories where broader market buzz has moved faster

• Teams that want the biggest ecosystem gravity or default-enterprise familiarity

Best fit:

• Engineers who want a real native multi-model database

• Teams that care about coherence more than trendiness

• Workloads where graph and document both matter

Poor fit:

• Buyers who mainly optimize for market dominance, vendor comfort, or the broadest default talent pool

Short verdict:

One of the cleanest narrower native multi-model databases on the market, but not the broadest expression of what a true multi-model system could become.

OrientDB

OrientDB deserves more than a polite historical footnote.

Supported models:

Model Support Notes

Document Native Part of its original identity.

Graph Native Part of its original identity.

Key-value / object-style access Native Part of the broader platform identity.

Search Supported Present, but not a central reason people choose it.

Vector Not original native identity Not part of the original core story.

Time-series Not original native identity Not part of the original core story.

It was early, and in many ways it helped make the category legible.

Its blend of document and graph ideas was ahead of what many teams were ready to appreciate at the time, and the database still has a clear point of view: relationships should be first-class, and the graph model should not be bolted awkwardly onto a system that only really wants to be a document store.

More importantly, OrientDB matters because it is part of the lineage that leads directly to ArcadeDB.

Luca Garulli created OrientDB, and after SAP acquired OrientDB and the project lost momentum, he started ArcadeDB from scratch. That history matters because ArcadeDB is not just "another graph/document database." It is also a reaction to the limits of an earlier generation.

That said, being early is not the same as staying strong.

OrientDB still has a real multi-model identity, and its SQL-extended graph approach is more approachable than some people expect. But it does not feel like the strongest current answer anymore. Momentum matters. Ecosystem energy matters. Confidence compounds around the systems that keep attracting builders, operators, and production stories.

This is where OrientDB now feels split between historical importance and current competitiveness. Historically, it helped define the category. Today, it feels more like an older expression of the idea than the place where the idea is moving fastest.

Category Score Why

Native multi-model support 7/10 Clearly part of its design identity, but narrower and more dated than the strongest current native multi-model systems.

Multi-model depth 4/10 Real graph-document roots are there, but the current implementation now feels much shallower than the stronger systems in this category.

Performance potential 6/10 Respectable, though the category has moved on.

Developer experience 6/10 More approachable than some graph systems, but not especially modern-feeling now.

Operational simplicity 6/10 Usable, but not where it shines.

Ecosystem / maturity 5/10 Historically important, currently less energetic.

Production confidence 5/10 Still capable, but not where I would place the strongest trust today.

*Trust review: *

Medium-low. Historically important, still usable, but no longer the place I would look first for the strongest current answer.

Query model:

OrientDB took a pragmatic route that still deserves respect: use SQL, then extend it for graph behavior. That made the system more approachable than graph databases that demanded a whole new way of thinking from the user.

Engine / storage shape:

OrientDB’s identity was always more engine-native than extension-driven. Graph relationships as physical links were part of its pitch and part of why it felt different from databases that only simulated graph behavior through foreign keys or application logic.

How native is the multi-model claim?

Strong historically. This is not a fake multi-model database. The real problem is not the category claim. The problem is that the implementation no longer feels like the sharpest current form of the category.

Where it feels first-class:

• Historical graph-document design thinking

• SQL-extended graph accessibility

• Category significance

Where it feels second-class:

• Current momentum

• Ecosystem energy

• Feeling like the sharpest modern implementation

Best fit:

• Readers trying to understand the category’s evolution

• Teams already invested in OrientDB

• Cases where its model still fits and organizational trust already exists

Poor fit:

• Greenfield teams looking for the strongest current multi-model bet

Short verdict:

Important historically, still usable, but now much more of a middle-to-shallow legacy native system than a leading current expression of the idea.

ArcadeDB

ArcadeDB makes the most sense when you see it as a second attempt at part of the same problem.

Supported models:

Model Support Notes

Document Native First-class part of the core design.

Graph Native First-class part of the core design.

Key-value Native First-class part of the core design.

Search Native engine capability Part of the broader native engine story.

Vector Native claim Part of the broader native engine story, but still less validated than older core models.

Time-series Native claim Part of the broader native engine story, but still less validated than older core models.

Relational-style querying SQL surface Available through SQL, but not a classic relational engine identity.

That is why I would not compare it to OrientDB as if they were unrelated products from unrelated teams. ArcadeDB is what happens when the original creator of OrientDB comes back and says, in effect:

the category idea was right, but the implementation needs to be rebuilt on a stronger foundation.

That is the interesting part.

ArcadeDB is not just carrying over the old multi-model ambition. It is trying to fix engine-level problems, performance limits, and architectural constraints that older systems ran into. That is why the "from scratch" part matters. If you believe multi-model databases need tighter control over storage, execution, and concurrency to compete seriously, then ArcadeDB is one of the more credible efforts in the space.

Its native multi-model story is strong: graph, document,** key-value*, **search, **vector, and *time-series are part of the same broader engine story, not just a loose product slogan. It also supports multiple query styles, which makes it unusually flexible for mixed workloads.

More importantly, the system looks like it cares about engine quality.

That matters because many multi-model databases are conceptually attractive but mechanically thin. ArcadeDB feels much closer to** a database that actually wants to own the hard parts instead of only smoothing over them at the API layer**.

Category Score Why

Native multi-model support 9/10 One of the strongest native stories in the category, with a broader native model claim than ArangoDB.

Multi-model depth 8/10 Serious scope and strong implementation ambition, with broader engine-level depth than most of the field even if some newer model claims still need more long-term validation.

Performance potential 8/10 The engine ambition is real, not just marketing.

Developer experience 7/10 Good enough, though not the smoothest or most mainstream experience.

Operational simplicity 6/10 Reasonable, but still not a default-operational choice for most teams.

Ecosystem / maturity 5/10 Under-recognized and still relatively small in ecosystem gravity.

Production confidence 8/10 The implementation quality and technical direction inspire real confidence, even if the market signal is weaker than larger better-funded names.

Trust review:

High on implementation quality, medium on market-proven confidence.

Query model:

ArcadeDB is unusually broad here. It supports SQL, Cypher, Gremlin, GraphQL, a Java API, and MongoDB query compatibility. Normally I would see that as a warning sign. Too many query surfaces often mean a weak center. In ArcadeDB’s case, the more interesting question is whether the engine underneath is good enough to justify that breadth.

Engine / storage shape:

This is where ArcadeDB gets serious. Its official positioning is not just "we support many models." It is "we natively store graphs, documents, key-value, search, vectors, and time-series in a single engine." It also emphasizes ACID transactions, a persistent journal/WAL, embedded mode, server mode, and Raft-based clustering. Whether every claim is equally mature is one question. But the architectural ambition is much closer to a real database-engine argument than to pure developer-experience packaging.

How native is the multi-model claim?

Very strong in intent and design. If you take the official architecture story seriously, ArcadeDB is one of the most native multi-model claims in the whole category. The remaining issue is not whether it is native enough. The issue is whether the rest of the market has validated that depth at scale.

Where it feels first-class:

• Native multi-model ambition

• Engine seriousness

• Graph-document-key-value style workloads that benefit from tighter core control

Where it feels second-class:

• Ecosystem gravity

• Market awareness

• Broad mainstream production trust

Best fit:

• Engineers who care about engine quality

• Teams open to a smaller ecosystem in exchange for stronger design conviction

• Builders who see value in the OrientDB lineage but want a more modern rebuild

Poor fit:

• Organizations that optimize primarily for ecosystem size, hiring familiarity, or mainstream adoption signals

Short verdict:

One of the strongest real multi-model designs available today, and better than its current market visibility suggests.

So which ones feel the most real?

If I strip away brand power, cloud packaging, and category marketing, the databases that feel most convincing as actual multi-model databases are:

• ArcadeDB

• ArangoDB - but with a narrower native model spread

• SurrealDB - but with much more caution because breadth is not the same as depth

• OrientDB - mostly for historical importance rather than current strength

If I include practical production reality, the picture changes:

• PostgreSQL + extensions remains the most dependable broad platform

• ArcadeDB is more promising than its market visibility suggests, especially if you care about engine quality more than market noise

• ArangoDB is one of the cleanest native multi-model bets

• Couchbase and Cosmos DB are strong if your priorities align with their platform shape

• SurrealDB is still more of a bet on direction

That is the pattern I keep coming back to.

And it is also why I do not use a very loose definition of multi-model here.

For me, a true multi-model database is not just a system that does two or three models reasonably well. A lot of databases can do that.

The harder question is whether the database can natively support a broader set of serious data models, and whether those models still feel like they belong to one coherent engine instead of a stitched story.

That is why ArangoDB still earns respect from me, but it also explains why I do not treat it as the final expression of a broader true multi-model design. It is strong, but narrower.

The category is real. The need is real. But the implementations are not interchangeable.

Some systems are broad but not very native. Some are native but not mature enough. Some are production-safe but conceptually patchy. Some are elegant but still proving themselves.

Bottom-line summary table

Database Native multi-model support Multi-model depth Performance potential Developer experience Operational simplicity Ecosystem / maturity Production confidence

PostgreSQL + extensions 4/10 7/10 8/10 8/10 4/10 10/10 10/10

SurrealDB 9/10 3/10 6/10 8/10 6/10 5/10 4/10

Couchbase 4/10 5/10 8/10 7/10 7/10 9/10 8/10

ArangoDB 7/10 6/10 8/10 8/10 6/10 8/10 8/10

OrientDB 7/10 4/10 6/10 6/10 6/10 5/10 5/10

ArcadeDB 9/10 8/10 8/10 7/10 6/10 5/10 8/10

Or if you prefer visual summary:

Why Azure Cosmos DB is not in the table

Azure Cosmos DB is often marketed as a multi-model database, but I do not think it belongs in the same bucket as ArangoDB, OrientDB, ArcadeDB, SurrealDB, or even PostgreSQL + extensions.

Cosmos DB is best understood as a managed distributed platform with multiple APIs and compatibility layers. That can be commercially strong. It can be operationally useful. It can be the correct product choice for many Azure-heavy teams.

But that is not the same thing as being a native multi-model database.

If a platform exposes different APIs over its storage engine, that does not automatically make it equivalent to a database that natively models graph, document, key-value, vector, or time-series semantics inside one coherent engine and query design.

In that looser definition, almost any serious platform can start claiming "multi-model" once enough compatibility layers, services, or access paths are added.

That is the category confusion I want to avoid here.

So I left Cosmos DB out of the actual review table.

Its real strengths are:

• Managed global distribution

• Enterprise cloud operations

• API-level flexibility

• Platform packaging

So where does NodeDB stand in all of this?

It is the new kid in the block, and that is exactly what makes it interesting to me.

It is trying to compete in a space full of established names, but it is not trying to copy their tradeoffs. The whole point is to chase both width and depth at the same time: broader native model support than the narrower systems, but with more serious engine-level realization than the systems that only look broad at the product layer. That is an ambitious target, and it is obviously much easier to say than to deliver. But that is also why it is worth talking about.

In the next post, I will shift from industry comparison back toward NodeDB and explain what I want to preserve, avoid, and do differently after looking at the current landscape.