Is it a bad practice to use mutable records for database entities?

C# 9.0 introduced records for more data oriented structures. I would like to use them for entity-objects that are used with some sort of ORM (like Dapper), because they provide a lot of useful functionality like value based equality. I believe one suggestion or good practice is to keep records immutable (init only), but this would mean a lot of copy operation when altering the entities in the business logic. Is it an acceptable practice to use mutable records for database entities?

Here is where I think the problem is: You want to use mutable records because you want to alter your database entities in the business logic. This immediately disqualifies these objects from being pure database entities. You should now look at them as domain entities that happen to have 1:1 matching with you database objects.

Is this wrong? Not necessarily. But it tightly couples how you handle these objects in your application layer with how they are stored in your database. There are many cases when this is not a good idea. Domain and Persistence are two different worlds. So, you may need to think about this.

Now, should you use mutable records for domain entities? I don't see a problem doing this. But it might/should not end there. Typical domain entities are expected to have some logic (behaviour) encapsulated in them. That is at least the essence of domain-driven design. So, not only will you have mutable properties in your records, but you will also have custom-defined methods. Again, I don't see a problem doing this in the cases where you want to benefit from the auto-generated code you get with records. But personally, I will only do it when it's absolutely needed. Otherwise, I will just use classes.