About half a year ago, I posted about my open-source package Eftdb, which adds TimescaleDB support to the Npgsql provider for EF Core. Since then, a lot has happened (well, at least for a side project).

Repository: https://github.com/cmdscale/CmdScale.EntityFrameworkCore.TimescaleDB

New Features & Improvements

• Continuous Aggregates & Policies: Added support for creating and managing continuous aggregates, alongside automated refresh policies.
• Data Retention Policies: Introduced built-in support for data retention policies to automatically drop old chunks and manage storage.
• Extended Compression Control: Added SegmentBy and OrderBy configuration options for fine-grained control over hypertable compression.
• LINQ time_bucket Support: You can now write time_bucket queries directly in LINQ using the new EF.Functions.TimeBucket() extension.
• Apache Community Edition: Expanded compatibility to support the TimescaleDB Apache Community Edition.
• Naming Conventions: Added seamless support for EFCore.NamingConventions.
• Scaffolding Fixes: Resolved database-first scaffolding bugs to ensure round-trips produce working migrations.
• Upgraded to .NET 10: Updated the target framework to .NET 10.

Developer Experience Improvements

• Open-Sourced Documentation: Moved all docs directly into the GitHub repository so anyone in the community can easily read, edit, and contribute.
• Codecov Integration: Added transparent test coverage tracking.
• Streamlined Repository: Implemented a much cleaner folder structure and revamped the CI/CD release workflows to use trusted publishing and GitHub Releases.
• Additionally, a lot of minor bugs have been fixed.

What I plan next

First, I want to improve the code generation. While I had a lot of experience with EF Core before starting this project, I had never dived this deep into its core mechanisms where there is often no documentation aside from the open-source code itself. I've learned a lot through this process.

Therefore, I want to improve the scaffolding process so it uses the already implemented Fluent API methods and Data Annotation attributes instead of generating a bunch of .HasAnnotation(...) calls. I also want to implement real extension methods for the migration files instead of spamming .Sql() calls.

After giving the project a little makeover, I want to add support for more TimescaleDB query functions through EF.Functions.

I also plan to add support for TimescaleDB's Hypercore feature.

---

This post is obviously self-promotion, but I also want to hear your honest (constructive) feedback, as it always helps me improve the project.

Also, I am incredibly thankful to everyone who has contributed — whether it was by reporting bugs, submitting feature requests, or creating pull requests to push the project forward. ❤️

---

P.S.: I am still torn on replacing .Sql() calls with dedicated extension methods in migration files. On one hand, I like the transparency of seeing exactly what SQL will be executed at a glance. On the other hand, extension methods are probably much cleaner.

What do you prefer in your migrations: clean extension methods like .CreateHypertable() or the transparency of raw .Sql("SELECT create_hypertable(...)") calls?