If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.

If your application is stateless following your definition then it's trivial to break the monolith down to microservices that focus on a bounded contexts while sharing a common db. This is a very well known microservices pattern.

https://microservices.io/patterns/data/shared-database.html

Yes, and what does that buy you? Instead of a single deployable unit that owns the database, there are many deployable units, none of which can own the database. That doesn't seem like an improvement.

Martin Fowler lists the benefits of microservices as

Strong module boundaries

Independent deployment

Technology diversity

And with a single database you severely limit the benefits from strong module boundaries and independent deployments. Suddenly you have to synchronize deployments, and anyone can pull or change any data in the database which now must be enforced with discipline which gets you into the same boat as a monolith.

> which gets you into the same boat as a monolith

Only worse because you don't have tools (IDEs, linters, etc) telling you what parts of the code have to be changed.

You can still wind up with distributed state errors. Ex:. User requisitions a billable resource, request hits node A. User immediately terminates billable resource, hits node B. Requisition request has a long latency (and termination request does not). So in the billing system, there is a negative time associated with the resource.