It has been a while since I last wrote here. I moved to Sweden, and that transition took more time and energy than I expected. A lot happened in between, but I am back now and ready to keep sharing what I have been building and learning.
This post is about CloudStorageORM, a project I have been working on as a way to think about what an ORM-like abstraction for cloud storage should look like. In practice, that means trying to make blob storage easier to work with from .NET without pretending it is a relational database. I’ve seen some JDBC drivers for some Cloud Providers in Java, so I wanted to see if I could do something similar in .NET.
What CloudStorageORM is trying to solve
Cloud storage is simple at the surface and messy in real projects. You usually need to store files, manage metadata, keep naming consistent, and make it easy for application code to read and write objects without coupling everything to storage-specific details.
CloudStorageORM sits in that space. The idea is to provide a more natural .NET experience for working with cloud storage, especially when the storage layer is part of the application domain and not just a raw bucket of files.
That distinction matters. The goal is not to hide cloud storage completely. The goal is to make common operations easier while still respecting the reality of blob storage.
Good use cases
CloudStorageORM makes the most sense when the application needs a structured way to manage blobs and metadata, but does not need a full database.
File and document storage
This is the most obvious fit. Think about applications that store PDFs, images, invoices, exports, reports, or user uploads. You want:
- A clean API for saving and retrieving content
- Metadata alongside the file
- Predictable naming and organization
- Less boilerplate in the application layer
Domain objects backed by blobs
Sometimes the blob is not just an attachment. It is the primary representation of a domain object, such as a generated report, a serialized document, or a versioned artifact. In those cases, an ORM-style abstraction helps keep the code readable and consistent.
Internal platform services
If you are building shared services or internal tooling, CloudStorageORM can be useful as a small but opinionated layer that standardizes how teams interact with blob storage.
Migration helpers
It can also help in migrations where applications need to move away from file-system storage or ad hoc storage code and adopt a cloud-native approach without rewriting every call site at once.
Where to use it
I would use CloudStorageORM when these conditions are true:
- The data is naturally file-like or object-like
- Metadata matters, but not enough to justify a relational model
- Query patterns are simple and mostly based on known identifiers
- The application benefits from a higher-level .NET abstraction
- The team wants less storage-specific boilerplate in business code
In short: use it when cloud storage is part of the application design, not when it is just a passive dump for bytes.
Where not to use it
This is where it is important to be honest. Not every problem should be solved with a storage abstraction.
Not a replacement for a relational database
If your data needs joins, transactions across multiple entities, foreign keys, strong relational constraints, or complex reporting queries, this is not the right tool. SQL Server, PostgreSQL, or another relational engine is the better choice.
Not for heavy query workloads
Blob storage is great for retrieving objects by name or path. It is not a good fit for ad hoc querying across large datasets. If your application needs rich search or filtering, you should add a search/indexing layer instead of pushing that responsibility into the storage abstraction.
Not for high-frequency updates to the same record
If the workload involves constant partial updates, concurrency-heavy edits, or record-level locking semantics, object storage can become awkward quickly. Blob storage is much better for read/write object flows than for highly transactional workflows.
Not for everything just because it is convenient
It is easy to over-abstract storage. If the application only needs a single blob upload and download, adding an ORM-like layer may be unnecessary complexity. Use the simplest thing that solves the problem.
What could be improved in a future version
For future versions of CloudStorageORM, I want to focus on a few practical areas.
Better developer experience
The API should stay simple, but it should also feel idiomatic in .NET. That means stronger async support, clearer patterns for dependency injection, and better guidance around serialization and metadata mapping.
Concurrency control
Blob storage often needs optimistic concurrency through mechanisms like ETags. A future version should make that easier to use so applications can avoid accidental overwrites.
Streaming and large object handling
Large files should not force unnecessary buffering. Streaming APIs would make the library safer and more efficient for real-world uploads and downloads.
Query and indexing support
Even though this is not a database, many applications still need to list, filter, and inspect stored objects. Better support for metadata-based filtering and listing patterns would help a lot.
Documentation and samples
This is always worth improving. Good samples, realistic scenarios, and clear recommendations about what the library is and is not for make a project much easier to adopt. I will be launching another app soon that will use CloudStorageORM, and I want to make sure it serves as a good example of how to use the library effectively.
Final thoughts
CloudStorageORM is interesting because it sits at a practical intersection: cloud storage, .NET ergonomics, and application design. That is also why it needs clear boundaries. It should make blob storage easier to use without pretending to be something it is not.
For me, the value of the project is not only in the code itself, but in the architectural conversation it encourages. It is a reminder that abstractions are useful when they reduce friction, but dangerous when they hide the real nature of the system.
I am glad to be writing again after the move to Sweden, and I have a few more things in the pipeline. More soon.
If you want to check out the project, you can find it here: CloudStorageORM.
