Logically sharing DB is not recommended in most cases, due to the two teams will depend on eachother to evolve the schema, they will not be autonomous, so in practice you may end up with a distributed monolith. You may find reading about event-driven architectures useful if you go microservices.
If you really need to use the same database without "code duplication" from 2 services, and you use the same tech stack, you can create a shared lib with the repository/entities and other common parts of the system. Just treat this lib as any other 3rd party lib, this mindset helped us architecting our microservices.
But: "code duplication" is not bad if you have multiple autonomous teams. If you consider the DB schema as some kind of contract, and only one team owns it, then other teams can develop their own APIs (repositories, entities) accessing this schema, with their preferred tools/tech stack, etc... I would not even consider this code duplication.
Another idea is to create an API layer above the DB (a 3rd microservice maybe?), and use this API from the other services to query/update data. This way the DB can change, and API should remain more stable, but you may lose transactionality this way.
Choose whats the most economic, developer-friendly or best for short/long-term for your project.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…