Unifying SQL and NoSQL without abstracting them away

Unification ≠ Abstraction

QoreDB doesn't try to make you believe that SQL and NoSQL are variants of the same model.
They aren't.

The goal isn't to smooth over their differences, but to let you work with them in a single tool without losing meaning, power, or control.

This approach can be summed up as:

standardize the structure, preserve the semantics.

A deliberately anti-ORM approach

ORMs (Prisma, TypeORM, Hibernate) and certain abstraction layers (ODBC, JDBC) try to hide the differences between engines.

They introduce:

• an intermediate language,
• an impoverished common model,
• structural limitations tied to what they're able to interpret.

QoreDB takes the opposite approach.

It never tries to translate your intent.
It gives you a direct channel to the database engine.

1. Unified lifecycle, native execution

The heart of the backend rests on a shared trait: DataEngine.

This trait standardizes only the lifecycle, not the language.

What is unified (the container)

The following operations are common to every engine:

• connecting
• listing namespaces (databases)
• listing collections or tables

This lets the interface display:

• a consistent navigation tree,
• a stable organization, whatever the engine.

What stays native (the content)

The central method is deliberately simple:

QoreDB never transforms the query.

• PostgreSQL: pure SQL (SELECT, CTEs, window functions)
• MongoDB: pure JSON (find, aggregate, complex pipelines)

The query is passed as-is to the native driver.

2. Two editors, two languages, zero translation

This decision is visible in the interface.

The frontend doesn't offer a generic editor.
It explicitly exposes two distinct environments:

• a dedicated SQL editor
• a JSON-based MongoDB editor

No mechanism tries to convert:

• SQL into MongoDB,
• MongoDB into SQL.

The developer's intent is never interpreted.
It's respected.

3. A hybrid type system, not a lowest common denominator

QoreDB doesn't force NoSQL into a relational table.
Nor does it force SQL into arbitrary JSON.

The type system reflects that reality.

A value can be:

• strictly typed (integers, text),
• a rich JSON document,
• a nested structure.

The direct consequences:

• a MongoDB query returns a complete JSON document,
• a SQL query returns typed columns,
• no forced conversion into an impoverished universal model.

The data keeps its original structure and semantics.

4. No magic "query layer" at all

In QoreDB there is:

• no intermediate AST,
• no generic query builder,
• no proprietary language.

This means:

• access to 100% of the engine's native features,
• no limitations imposed by the tool,
• no gap between what the database can do and what the tool allows.

An ORM limits you to what it understands.
QoreDB lets you talk directly to the database.

Conclusion

QoreDB unifies the experience, not the models.

It provides:

• a common entry point,
• consistent navigation,
• uniform visualization.

But it refuses:

• to translate queries,
• to flatten data,
• to invent an intermediate language.

QoreDB isn't a translator.
It's a hub.

A tool that respects the diversity of engines
instead of artificially hiding it.