Singleton Pattern + unavoidable Public Constructor
The question is: what do you want to achieve.

As you store the singleton in the database it seems to me that your singleton is semantic and not technical.

Technical singletons have that unified structure of static instance field, maybe lazy initialization and private constructor to ensure only ONE instance per JVM.

Semantical singletons do not have the assertion to be unique per object identity in the JVM. Their assertion is they BEHAVE the same EVERYWHERE and they have semantic identity (equals) in ANY JVM to ensure identity beyond JVM boundaries.

Often this kind of singleton is used to have a central entry point to a domain/module.

To avoid the public constructor in the semantic singleton I have separated the requirement "central entry point" from "object instantiation". In my design I have a SingletonX class that adresses "central entry point". Furthermore I have a class X that is more or less a POJO Finally I have an interface InterfaceX to redefine the public interface of class X. Class X should be resolved at runtime and is mostly out of scope to be instantiated through client code. Class X is the class to be serialized.