"Your app's data is never stored on our servers with the exception of edit history which lets you audit all changes to your data" from: https://www.basedash.io/pricing
Not the most convincing sell but not that they did not address this concern at all.
What happens if you have a field that's supposed to be 0-9, but it's an int field and someone types in 22 on accident? Sure it might be valid for the database, but it's not valid for the application.
There's certainly different ways to take the problem, but it needs to be considered.
This is why database constraints exist.
Any sufficiently long lived database ends up with more than one code base connected to it. Enforcing rules in the database ensures a baseline level of data sanity.
But ....
In the wild, database constraints are rare. I even often see databases without any foreign key constraint.
We have a new client like that. application developed in the past 3 years on postgres, uses all the buzzwords (microservices, Kubernetes, terraform, ...). The only constraints in database is on primary keys. The site moves up to 500k EUR per day.
This is far from rare.
What comparative ORMs do you use for non-django, or non-python languages?
Unfortunately, I think a lot of new developers resort to MongoDB because they think it's better for early stage evolving schemas. It's certainly more open to changing your schema on the fly, but perhaps not for the better.
Yes an audit log may help you notice these and fix them, but that's probably not going to be enough for anyone running a product in production off this database.