RepoDB’s New Architecture - Productivity, ORM, Low-Level Connectors and Insights

RepoDB has grown from a single hybrid-ORM library into a small family of packages — connectors, bulk operations, and now RepoDB Insights. It’s a good point to step back and lay out how all of it fits together. The diagram below is the mental model going forward, and this post walks through every box and the connections between them.

Reading the diagram

There are two halves. On the left, a three-layer stack — Productivity, ORM, and Low-Level Connectors — stacked top to bottom, with an arrow flowing from Productivity down into ORM, and another from ORM down into Low-Level Connectors. On the right, an Insights column fed by an arrow branching off from the ORM layer.

The downward arrows describe a dependency, not a runtime call order: each layer is built on top of the one below it. Low-Level Connectors is the foundation that talks to the actual data source; ORM sits on top of it and is what most developers interact with directly; Productivity sits on top of ORM and packages common multi-step operations into single calls. The sideways arrow into Insights represents telemetry — every operation that flows through the ORM layer is also the point where operation-level telemetry gets captured and shipped off to Insights.

Low-Level Connectors — the foundation

This is the bottom-most layer, and it’s the layer that owns the actual wire protocol conversation with a data source. It’s where System.Data.Common-based ADO.NET providers live — the same category of component covered in Introducing RepoDb.Connector.MariaDb.

• MariaDB Connector — RepoDb.Connector.MariaDb, a dedicated DbConnection/DbCommand/DbParameter implementation for MariaDB, prefixed so it never collides with the existing MySQL-flavored types.
• Many More ODBC Connectors — the broader set of ADO.NET-shaped connectors RepoDB already ships or plans to ship for other relational engines, following the same per-provider pattern used for SQL Server, PostgreSQL, and Oracle.
• File Connectors (Delta, etc) — connectors that speak to file-based table formats such as Delta Lake, so the same programming model can reach data that doesn’t live behind a traditional database server.
• Cloud Data Warehouse/Lake Connectors — connectors targeting cloud-hosted warehouses and lakes (the kind of destination that increasingly sits next to a traditional RDBMS in a modern data estate).

None of these boxes know anything about RepoDB’s ORM features. They only expose a standard ADO.NET surface — the same design principle already shipped in RepoDb.Connector.MariaDb, where the connector composes with RepoDB, Dapper, or hand-rolled data access code equally well.

ORM — the core programming model

This is the layer most RepoDB users already know. It’s built directly on top of whichever Low-Level Connector is in play, and it’s where RepoDB’s extension methods over IDbConnection live.

• CRUD — the single-entity Insert/Query/Update/Delete operations RepoDB is best known for.
• Batch CRUD — the batched equivalents (InsertAll, UpdateAll, DeleteAll, etc.) that operate over a set of entities in controlled-size batches.
• Bulk CRUD — provider-native bulk operations (BulkInsert, BulkUpdate, BulkMerge, BulkDelete) built on top of each provider’s bulk-loading mechanism, such as the LOAD DATA LOCAL INFILE-based bulk copy shown for MariaDB.
• Multiple DB Support — the fact that this entire surface is provider-agnostic: the same CRUD/Batch/Bulk calls work whether the underlying connector points at SQL Server, PostgreSQL, MariaDB, or anything else with a registered extension.

The arrow from ORM up into Productivity means the Productivity layer is written in terms of these operations, not around them.

Productivity — higher-level, multi-step operations

The top layer packages common multi-step data tasks — the kind of thing you’d otherwise hand-roll out of several CRUD/Batch/Bulk calls — into single, purpose-built operations.

• Move — relocate rows from one table (or database) to another.
• Copy — duplicate rows without removing them from the source.
• Merge — reconcile two sets of rows using key-based matching, the productivity-level counterpart to Bulk CRUD’s BulkMerge.
• Deduplicate — identify and remove duplicate rows based on a defined key or comparison.

These are the operations aimed at data-maintenance and migration scenarios, where the unit of work is “move this data around correctly” rather than “manage this one entity.”

Insights — where telemetry goes

The Insights column sits to the right, fed by the arrow branching off the ORM layer. That branch point is deliberate: ORM is where every operation actually executes against a connection, so it’s the natural place to observe what’s happening and emit telemetry about it.

• Default Telemetry — the already-shipped path, covered in Getting Started with RepoDB Insights Default Telemetry. It hooks directly into RepoDB’s own before/after execution events and ships a lightweight payload to the RepoDB Insights stack — no Span/Activity machinery, no collector protocol overhead.
• OTEL Telemetry — the planned, opt-in counterpart for teams that need vendor-neutral, OpenTelemetry-shaped export into an existing observability stack (distributed tracing across services, standard collector protocol). It’s called out in the Default Telemetry announcement as a separate package still on the roadmap, not yet shipped.

Both boxes represent the same underlying idea — observability over what RepoDB is doing — just with two different tradeoffs: Default Telemetry optimizes for a thin, fast, zero-fuss path; OTEL Telemetry (when it ships) will optimize for interoperability with the broader observability ecosystem.

Why this shape

Keeping Low-Level Connectors, ORM, and Productivity as separate, stacked layers is what let RepoDb.Connector.MariaDb ship independently of any ORM-level change, and it’s what will let future Productivity operations (Move, Copy, Merge, Deduplicate) reuse Bulk CRUD internally instead of reimplementing bulk-loading logic per operation. The same separation is why Insights can branch off the ORM layer as an observation point without either layer needing to know about the other’s internals — Default Telemetry shipped first, and OTEL Telemetry can be added later without touching CRUD, Batch CRUD, or Bulk CRUD at all.

Putting it together

Here’s what the ORM and Low-Level Connectors layers look like combined: stream from Oracle into BulkInsert against both SQL Server and MariaDB.

using var source = new OracleConnection(oracleConnectionString);
source.Open();

using var sqlServer = new SqlConnection(sqlServerConnectionString);
using (var reader = source.ExecuteReader("SELECT * FROM Customer"))
    sqlServer.BulkInsert<Customer>(reader, tableName: "Customer");

using var mariaDb = new MariaDbConnection(mariaDbConnectionString);
using (var reader = source.ExecuteReader("SELECT * FROM Customer"))
    mariaDb.BulkInsert<Customer>(reader, tableName: "Customer");

Each reader is an IDataReader — never fully materialized in memory. BulkInsert pulls rows from Oracle and streams them straight into the destination as it reads, one connector underneath, one ORM call on top, regardless of which two providers are on either end. A reader is single-pass, so each destination gets its own ExecuteReader against the source rather than sharing one across both calls.

And with productivity platform, below is the code.

using var source = new OracleConnection(oracleConnectionString);
source.Open();
source.MoveTo(SqlConnection(sqlServerConnectionString), nameof(Customer));

Because it’s streaming rather than buffering, this same code scales to a Customer table with a few rows or a few hundred million — the memory footprint stays flat either way. And because it’s running through the ORM layer, it’s the same layer the Insights branch observes: each BulkInsert is a monitored operation, so a move like this shows up in Default Telemetry (or OTEL Telemetry, once shipped) the same as any other RepoDB call.

What’s next

Several of these boxes are still ahead of us — more ODBC connectors, File and Cloud Data Warehouse/Lake connectors, the Productivity operations, and OTEL Telemetry. Expect dedicated posts as each one lands, the same way RepoDb.Connector.MariaDb and Default Telemetry got their own deep dives.

• GitHub: RepoDB

  RepoDB.Connectors

• Feature docs: repodb.net

Please support us

Give a ⭐ to our Github repository | Follow me at X / Twitter | Connect with us at our official Teams Channel
Apache License 2.0 — Copyright © 2026 by Michael Camara Pendon / Create a Request

~ Conceptualized and written by me. Reviewed and checked by AI. Refined and gatekept by me. ~