You are right. Using Mongoose puts you in a spot similar to that of an SQL database design, except with worse performance.
However, this “ridged design” can be helpful. The concept that MongoDB gives you complete freedom to define your schema, and have dynamic data is both its primary advantage, and a disadvantage.
If your data is super flexible and dynamic you end up with a lot more pain, in regards to not knowing how to optimize it, or really deal with it. Sure your database is flexible but your code isn’t.
There’s also the issue of data validation. MongoDB doesn’t care what your data looks like. Mongoose can enforce some rules to help protect it, by providing protections “at the code level”, rather than the DB level.
In the super long run it might be, but I’d only take this route if the idea of rebuilding Mongoose from scratch is the only option. Otherwise you’re re-inventing the wheel. Its also possible your app would outgrow MongoDB by the time you get around to finishing your own version of mongoose.
Depending on the requirements, the less optimal performance in the best cases might prevent MongoDB from being viable at all. For example, Discord started with MongoDB when they launched, but then had to transition to Cassandra (another NoSQL database, but aimed at large scales)
The key advantage of using something like MongoDB initially is the ability to iterate. Mongoose will enforce some rigidness to that iteration process, but it also applies it to an area where you usually always want rigidness. That area is the apps data. The last thing your code wants is data that is so dynamic it isn’t sure what it even is. Not only does it make it harder to write your entire application stack, it also makes it near impossible to debug.
Having “clean” organized data doesn’t mean you can’t also iterate quickly by simply making changes to the code to add new properties. This is in comparison to an SQL database that forces you to run a migration to update the tables and deal with any possible issues in that regard.
There is also the concept that understanding how to use MongoDB by itself is useful for later picking up mongoose to handle other cases Mongo doesn’t. As it isn’t an either or. You can use Mongoose for most things, then pull up an aggregate
for situations where Mongoose wont cut it, or you need to optimize what you’re doing without getting “sandboxed” into just using what Mongoose provides.
The choice is ultimately up to you.
Good luck, keep learning, keep building