The Driver Model in QoreDB: Choices, Constraints, Limits

A Shared Kernel, Native Engines

QoreDB’s driver model rests on an architecture that can be summed up as follows:

A single kernel, with native drivers built in.

QoreDB uses none of the following:

• ODBC / JDBC (full abstraction),
• JavaScript drivers running inside an Electron layer,
• intermediate query translation.

Each engine is implemented natively in Rust, compiled into the binary, and exposed through a minimal shared interface.

This choice imposes real constraints.
It also brings strong guarantees in terms of control, performance, and architectural clarity.

1. Isolation per session

The “1 session = 1 pool” pattern

In QoreDB, each tab or user session instantiates its own connection context.

Concretely:

• PostgreSQL uses a dedicated PgPool per session.
• MongoDB uses a dedicated Client per session.

Main advantage: total isolation

A blocked session, a heavy query, or a crash never affects:

• the other tabs,
• the other connections,
• the application’s global state.

Each session is an isolated space.

Direct constraint: connection consumption

This approach has a measurable cost.

For example:

• 1 pool = 5 connections max (default)
• 10 tabs open on the same database
• up to 50 simultaneous connections possible

QoreDB favors isolation and robustness over aggressive optimization of the connection count.

This is an explicit choice.

2. “Fake SQL” for NoSQL

A controlled concession

The unified DataEngine interface enforces a single, simple method:

execute(query: &str)

For PostgreSQL, this poses no problem:
the language is SQL.

For MongoDB, the situation is different.

The reality on the MongoDB side

QoreDB does not execute JavaScript in the Mongo editor:

• no loops,
• no variables,
• no procedural logic.

The driver expects strict JSON, representing a native Mongo command.

How it works:

• if the input is valid JSON (find, aggregate, etc.), it is executed directly;
• if the input resembles a syntax such as db.users.find(...), a syntactic fallback attempts to convert it into JSON.

An accepted limitation

QoreDB’s Mongo editor is a query editor, not a scripting environment.

This is a deliberate constraint:

• simpler to secure,
• more predictable,
• aligned with the rest of the architecture.

3. Schema inference for NoSQL

A necessary approximation

MongoDB is schema-less by definition.
The interface, however, needs a structure for:

• the navigation tree,
• autocompletion,
• the results grid.

The chosen solution is inference by sampling.

How it works

To describe a collection:

• QoreDB reads the first 100 documents,
• infers a probable structure,
• exposes it to the interface.

Structural limitation

If a field:

• appears rarely,
• or only in later documents,

it may not show up in:

• autocompletion,
• the displayed structure.

QoreDB does not invent a global schema.
It shows a partial but honest view of reality.

4. Transactions: an accepted asymmetry

Transactions are handled according to the engine’s actual capabilities.

PostgreSQL

Full support.

• A transaction reserves a dedicated connection from the pool.
• All queries pass through this single channel.
• The transaction is strictly honored until COMMIT or ROLLBACK.

MongoDB

The driver detects at startup whether transactions are supported.

Critical limitation:

• MongoDB in Standalone mode (the typical local case) does not support transactions.
• They are only available on Replica Sets.

QoreDB:

• does not emulate them,
• does not simulate them,
• does not lie to the user.

If the engine does not support a feature, the tool does not fabricate it artificially.

5. Streaming and performance

Never load everything into memory

A classic problem with Electron-based desktop tools:

• massive loading of results into memory,
• full serialization to JSON,
• a frozen interface.

QoreDB takes a different approach.

How it works

The drivers implement a streaming mode:

• results are read row by row (or in batches),
• flow through asynchronous Rust streams,
• are sent progressively to the frontend.

At no point:

• is the entire dataset loaded into RAM,
• does a large SELECT block the whole application.

This is a structural choice that keeps QoreDB usable on very large volumes.

Conclusion

QoreDB’s driver model is not neutral.

It:

• favors isolation over extreme optimization,
• prefers explicit limits over misleading abstractions,
• exposes the engines’ real capabilities instead of artificially unifying them.

QoreDB does not try to be smarter than the databases it works with.

It strives to be:

• a reliable intermediary,
• an honest executor,
• a tool that does not hide complexity, but makes it manageable.