It started as a hobby project that I worked on during nights and weekends, and it still is one. But somewhere along the way it grew into a library that real developers rely on in real applications. Every feature, every bug fix, every late-night refactor added up to something I am genuinely happy to put my name on. Looking back, I can say it plainly: this is my obra maestra, and I would not trade the journey for anything.

The Part I Will Miss

There is a part of this milestone that is bittersweet, and I would rather be honest about it.

RepoDB was born as a lightweight library. A hybrid ORM that stays out of your way, generates the SQL you would have written yourself, and does not ask you to adopt a heavy framework or a complicated mental model. That simplicity is what made it feel right, and it is what many of you fell in love with.

As I move RepoDB further toward a Data Productivity Platform for .NET, that lightweight version of the library is something I will miss. A platform carries more responsibility than a library. It has more layers, more capabilities, and more surface area to keep coherent. I am doing it on purpose, because I believe it is where the real value is, but I will not pretend the trade is free. The small, focused, easy-to-hold-in-your-head RepoDB is the one I grew up with, and I am going to miss it.

That said, the ORM is not going away. It remains the foundation that everything else stands on, and staying honest to its lightweight roots is a big part of how I intend to build the rest.

The Last 4 Months Were Only the Beginning

I also want to be clear that the last four months were an initial move, not the destination.

In that time I pushed RepoDB well beyond its original four providers. I covered the ground in Three Months of Growing RepoDB Across Database Providers, and I laid out the direction in My Vision for RepoDB and the four-layer architecture in RepoDB’s New Architecture - Productivity, ORM, Low-Level Connectors and Insights. All of that work was groundwork. It was about getting the foundation right, proving that the resolution model could absorb very different database engines, and separating the stack into layers so that Productivity, Insights, and the rest can be built once on top of it rather than reimplemented per provider.

The bigger picture is still ahead of us, and it will unfold over the next year and the years to come. What you have seen so far is the first few steps of a much longer road. There is a lot more I want to build, and I am more excited about it than I have been in a long time.

Thank You

Finally, and most importantly, thank you.

To the avid users of RepoDB: the ones who picked it up early, stayed with it through the rough edges, opened issues, sent pull requests, asked hard questions, and kept using it in production when they could have moved on. You are the reason this project exists past the point where it was just a personal experiment. Every message, every bug report, and every “this saved me hours” has kept me going on the nights when it would have been easier to close the laptop.

I do not take your trust for granted. I will keep working to earn it as RepoDB grows into what comes next.

Thank you for being part of this journey. More to come.

~ This post is refined by AI, but is reviewed and gatekept by me before posting ~

At the start of summer, RepoDB supported the four providers most people associate with it: SQL Server, SQLite, MySQL, and PostgreSQL. Since then, I have pushed support for Oracle, IBM DB2, MariaDB, MariaDB Connector, MySQL Connector, Firebird, Vertica, SAP HANA, ClickHouse, and EnterpriseDB. That is ten new providers in roughly three months, bringing the total to fourteen.

No Two Databases Play by the Same Rules

Going in, I expected the differences between these engines to mostly be syntax — a different way to write LIMIT, a different quoting character for identifiers. That assumption did not survive contact with the actual work.

Oracle does not allow multiple SQL statements to be packed into a single round-trip the way SQL Server does, which meant QueryMultiple needed its own round-trip strategy just for that provider. Its bulk operations also needed an entirely custom array-binding path, because Oracle’s ODP.NET driver does not expose anything close to SqlBulkCopy.

DB2 brought a different kind of pain: the official driver ships as a native shared library, and getting it to load correctly in CI, across Docker health checks and container startup timing, took more iterations than the actual data-access code did.

MariaDB looked like it should just piggyback on the existing MySQL support, since both speak a very similar wire protocol. But treating them as the same thing causes real collisions the moment both providers are registered in the same process. That is what pushed me to build a dedicated RepoDb.Connector.MariaDb, with every type prefixed so a MariaDbConnection and a MySqlConnection can coexist without stepping on each other, even though both ultimately talk to the server through the same underlying driver.

Firebird had no bulk-loading protocol at all in its ADO.NET driver, so I had to hand-roll a command batcher just to get bulk operations working at a reasonable speed.

Vertica ended up templated from that same Firebird groundwork, since its driver situation was similarly sparse. Unfortunately, there is no real support to wired-protocol bulk copy, ended up to Task.Run and flagged it.

SAP HANA’s bulk copy class only exposed a synchronous API, so making it behave asynchronously meant wrapping it with Task.Run or batch via command through custom batcher — a shortcut I am not fully comfortable with, and one I have flagged to revisit.

And ClickHouse was the biggest mental shift of the batch, because it is not a transactional row-store at all. There is no identity column, so RepoDB cannot hand you back a generated key the way it does everywhere else. There is no MERGE/UPSERT, so Merge compiles down to a plain INSERT and deduplication becomes a table-engine concern instead of a write-time one. Updates and deletes are background mutations, not immediate in-place writes. None of RepoDB’s existing assumptions about “a row” held up, and the provider had to be honest about that instead of pretending ClickHouse is just another RDBMS.

Where RepoDB Stands Today

As of today, RepoDB officially supports fourteen database providers:

• ClickHouse
• EnterpriseDB
• Firebird
• IBM DB2
• MariaDB
• MariaDB Connector
• MySQL
• MySQL Connector
• Oracle
• PostgreSQL
• SAP HANA
• SQL Server
• SQLite
• Vertica

Why RepoDB’s Resolution Layer Matters More Than Ever

None of this would have been sustainable if every provider needed its own bespoke way of being called. The reason a developer can write the same Query, Insert, Merge, or BulkInsert call against SQL Server, Oracle, or ClickHouse and have it just work is because RepoDB pushes all of that variance into a small, well-defined set of resolution points — the IDbSetting, IDbHelper, IStatementBuilder, and CLR-to-database-type resolvers each provider plugs in.

Those resolutions are where the real gap-closing happens. They are what let RepoDB decide, per provider, whether an identity value comes back from the server or has to be generated by the caller, whether a merge is a real MERGE statement or a fallback INSERT, whether a bulk load goes through a native binary protocol or a hand-rolled batcher, and how a .NET type maps to whatever native type that specific engine expects. Without that layer, “move data from one provider to another” would mean rewriting data-access code every time the destination changed. With it, the same repository code can target a completely different database engine, and the only thing that changes is which resolvers get registered.

That, more than any single provider, is the part of this three-month push I am proudest of. Getting Oracle, DB2, or ClickHouse working was a lot of grinding. But proving that RepoDB’s resolution model could absorb engines this different from each other — without bending the core API out of shape — is what tells me the architecture is sound enough to keep growing.

Rethinking the Architecture in Four Layers

Going through fourteen providers back to back also forced a bigger realization: RepoDB itself needed to stop being thought of as “one ORM library” and start being thought of as a stack. That thinking is what led to the four-layer architecture I laid out in RepoDB’s New Architecture - Productivity, ORM, Low-Level Connectors and Insights — Low-Level Connectors at the foundation, ORM on top of that, Productivity on top of ORM, and Insights branching off the ORM layer to observe everything flowing through it.

That separation is not just a diagram; it is a direct consequence of everything described above. Low-Level Connectors is where all of the provider-specific pain — Oracle’s array binding, Firebird’s hand-rolled batcher, MariaDB needing its own prefixed types — actually lives, isolated from the ORM surface. ORM is what stays provider-agnostic thanks to the resolution layer, so a BulkInsert call reads the same whether it targets SQL Server or ClickHouse. And once that separation exists, Productivity-level operations like Move, Copy, Merge, and Deduplicate can be built once, on top of Bulk CRUD, instead of being reimplemented per provider. It is the same closing-the-gap idea from the resolution layer, just one level higher: the boundary between fourteen very different databases collapses into a single, consistent surface for actually moving data between them.

What This Sets Up

Fourteen providers is not the finish line. It is proof that the model scales to genuinely different kinds of databases, transactional and analytical alike, which matters a lot if RepoDB is going to keep closing the gap between how different data platforms store and move data. There is still cleanup ahead — the SAP HANA async story being the most obvious one — but the foundation for the next batch of providers is in a much better place than it was three months ago.

More to come as this keeps moving.

~ This post is refined by AI, but is reviewed and gatekept by me before posting ~

Anders was the reason I fell in love with C# in the first place. Long before I ever wrote a single line of production code, I was drawn to the elegance of the language he designed, the way it balanced simplicity with power. He was not just someone who built a programming language; he was the reason I wanted to become the developer I am today. I always dreamed of truly mastering his creation, of becoming very good at the very thing he gave to the world.

That dream is what pushed me to put myself fully into C#. I picked it up from the very beginning of my career, twenty years ago, when I was still finding my footing as a developer. I stuck with it through every framework shift, every new version, every late night spent understanding why the language worked the way it did. C# was not just a tool I used, it became the foundation of everything I built, including my open-source work like RepoDB. Two decades later, that early decision to commit myself to Anders’s creation still defines who I am as an engineer and architect.

So when I learned he was speaking at the Patterns and Practices Convention at Microsoft Lyngby in November 2019, I knew I had to be there. Sitting in that room, listening to him talk about the language and TypeScript, and the thinking behind it, felt surreal. And when I finally had the chance to meet him face to face, to shake his hand and tell him what his work has meant to my career, twenty years of admiration came full circle in a single moment.

Meeting your greatest idol does not happen often, especially not one whose creation you have spent your entire career mastering. That day at Lyngby will always be, without question, the biggest day of my professional life.

The Cost Problem Every Big Data Platform Shares

Almost every enterprise company I have talked to or worked with runs into the same wall once their data platform matures: cost. It does not matter if it is Databricks, Confluent, DataIKU, or Azure Synapse — these platforms are powerful, but that power comes bundled with clusters, compute units, storage tiers, and licensing that scale in a direction that is hard to predict and even harder to control. Teams end up paying for capability they only use a fraction of, because the platform is built to handle everything at once rather than the specific thing your organization actually needs today.

That is not a knock on these platforms; they solve real problems at real scale. But “big platform for everything” is a very expensive default when most organizations do not need everything, they need a handful of things done really well.

The AI Era Removes an Old Constraint

For years, the reason companies bought into these all-in-one platforms was simple: they did not have the developer capacity to build and maintain something more tailored. Custom tooling was a luxury reserved for organizations with large engineering teams.

I think that constraint is no longer a hard blocker. In the AI era, a small team — or even a single developer — can move faster and cover more ground than an entire team could a few years ago. The organization no longer needs a large headcount to “do big things.” It needs the right small things, built well, and AI closes most of the gap that used to require that headcount.

The Idea: Small Pieces, Big Outcomes

This is where my idea starts. Instead of adopting one massive platform meant to do everything, what if the data platform was made of small, purpose-built pieces — each one lightweight, focused, and cheap to run — that together deliver the same outcomes big platforms promise, but without the overhead?

The core of it is rethinking how data and files are structured in the first place. Big platforms tend to assume you need their engine to make sense of your data. I think a more efficient structuring of data and files can remove a lot of that dependency, letting small components do the heavy lifting that today gets outsourced to a big, expensive cluster.

It is a completely different mental model from the big data platforms we are used to today. Instead of “one platform to rule the pipeline,” it is “many small, efficient pieces, composed to deliver the big result.”

Where This Goes From Here

This is still early — more of a spark than a blueprint. But it is the same instinct that got RepoDB started: a thin, efficient, transparent layer can often do more than a heavy one, at a fraction of the cost. I want to explore whether that same philosophy holds true at the data platform level, not just at the data access level.

If this resonates with you, or if you have run into the same cost wall with your own data platform, I would love to hear about it. This is the kind of idea that gets sharper the more it gets challenged.

This post contains what is on my head, but it is also refined by AI.

I am expressing the full me here without the influence of AI.

Having extensive experience in .NET and being exposed to Python in recent years has given me a lot of thoughts about the possibilities of what humans can do with data. I also believe that data is the area where we can accelerate businesses and help AI learn even more from it.

IMHO, and don’t quote me on this, being in .NET alone is just not enough to understand the entire Enterprise ecosystem. One must really work with the different technologies and tools that Enterprise companies use and truly understand the pain points of the business.

I am using that experience to further improve the capabilities of my masterpiece (obra maestra), #RepoDB. As a hobby project that I work on during my nights and weekends, I am very committed to bringing this ORM library beyond being just another ORM in .NET. My goal is for it to become a developer productivity tool for everyone in this ecosystem.

Some of the capabilities are shown below, including Insights visibility and Default Telemetry. (Note: What I have shared here represents only the ideas currently in my head and capabilities that are already common in Enterprise corporations. There are many more functions to come.)

Imagine that John can do this across multiple database providers, while I am currently busy expanding the ORM to Oracle, Db2, MariaDB, Snowflake, Firebird, Vertica, and many more. Or imagine Claude or ChatGPT recommending and generating this small piece of code for you—code that delivers advanced capabilities many Enterprise teams struggle to build themselves.

#DotNet #CSharp #ORM #Data #Productivity #Tools

The context behind this Tweet comes from years of working in .NET while also being exposed to Python, which has shaped how I think about data and what it takes to truly serve the Enterprise ecosystem. It is not enough to be fluent in one stack; you have to sit with the different tools and technologies that Enterprise companies actually use to understand where the real pain points are. That is the perspective I keep bringing back into RepoDB.

RepoDB started, and remains, a hobby project I work on during my nights and weekends, but my ambition for it has grown well beyond being just another ORM for .NET. I want it to become a developer productivity tool, one that gives every developer in this ecosystem capabilities that are already standard in Enterprise corporations but rarely accessible in an open-source library. Insights visibility and Default Telemetry are two concrete examples of that direction, and they are only the beginning of what I have in mind.

This is also why expanding provider support to Oracle, Db2, MariaDB, Snowflake, Firebird, Vertica, and more matters so much to me right now. The goal is for these productivity capabilities to be available across the providers Enterprise teams actually rely on, not just a single database engine. And looking further ahead, I imagine a future where tools like Claude or ChatGPT can recommend and generate RepoDB code that delivers this kind of advanced capability out of the box, capability that many Enterprise teams currently struggle to build themselves.

More on this as it takes shape.

Today he pulled off his 4th win, putting him just 1 win away from claiming the prize. He has been putting in real effort to sharpen his aim and game sense, and it clearly shows.

What really stood out was yesterday, when he easily topped the leaderboard in 5 straight Deathmatch games. Watching him grow more confident and consistent with every match has been a genuinely proud moment for me as his dad and coach.

One more win to go before that Knife skin is his. Rooting for you, Miggy!

Along the way, I have run into a good number of use-cases that RepoDB does not yet fully support for Oracle. Things like handling Oracle-specific data types, dealing with its distinct bulk operation behavior, and adjusting the internal query builders to align with Oracle’s SQL dialect are all requiring careful, deliberate work.

It has not been a quick or straightforward process, but every issue I uncover is helping me shape a much more solid and reliable implementation. I am pushing hard to get this right, since Oracle support is a key step toward making RepoDB a truly viable choice for enterprise environments.

More updates to come as this progresses.

Du har opnået følgende karakterer i Dansk 2

Læseforståelse:  7
Skriftlig fremstilling:   7
Mundtlig kommunikation:  7 

For at prøven anses som bestået, skal gennemsnittet af karaktererne være mindst 2,0 (karakteren i mundtlig kommunikation tæller dobbelt).

Dit gennemsnit er:  7,0

This is another milestone in my journey of learning the Danish language, and I am looking forward to continuing improving it.

The motivation behind adding Oracle support is to expand the footprint of RepoDB across more database providers, laying the groundwork for future enterprise-level capabilities. As RepoDB continues to grow, being able to support widely used enterprise databases like Oracle is an important step toward making it a viable option for larger, more diverse production environments.

There is still more work ahead, but this is a solid step forward in broadening what RepoDB can do.