Sometimes I stated writing a web app with Sinatra, which is about the less frameworkish thing you can do in Ruby unless you are also writing your own router.
I regularly end up having to
1. Either write my own code to query the db and build Ruby objects from the response and viceversa OR use ActiveRecord.
2. Same thing about managing the database schema. Either my own code or someone else's. So why not Rails' well tested one?
3. Organize the code base in some way that makes sense.
4. Write my own code to manage tests OR use rspec / capibara (OK, they are not part of a framework but they are a large dependency)
In the end I always regret I didn't use Rails from the beginning because I end up spending a lot of time doing useless takes. Keep in mind that I do that for my own projects in my free time. 99% of the times my customers decide what to use (Rails, Django, Phoenix.)
* It lets me pick and choose an ORM. I usually prefer Sequel over ActiveRecord. Pretty much nobody suggests you should use Sinatra without an ORM unless you genuinely don't need a database.
* Nobody suggests you should build your own schema management. Pick an ORM which provides it out of the box (e.g. Sequel), or use a component which provides it (e.g. Padrino has a generator component which out-of-the-box supports generating migration helpers for the major Ruby ORM's and some you're unlikely to have heard of)
* Nobody suggests you should write your own code to manage tests. Just use rspec / capybara, or whatever else you prefer. And again, consider using Padrino's generator if you want something to generate scaffolding for it for you.
The point of using Sinatra is the freedom to opt-in to your preferred components as and if/when needed. If you always want the ones Rails provide, just use Rails, nobody will think less of you for doing so. Not even those of us who personally don't like using Rails.
For my part I rarely want the ones Rails provide, and so I rarely use Rails. Often I use bare Sinatra. Sometimes I mix in some components from Padrino because they can be easily torn out again.
I'd suggest that if you want something lighter than Rails but have those issues with Sinatra, look at Padrino (Sinatra + a pre-packaged set of components you can opt in or out of separately, or layer in piece by piece on top of Sinatra if/when you need them). But you can also just use Rails.
Counterpoint, and let's assume mostly parity of flask :: sinatra and rails :: django.
I've usually used Flask and even when I needed a few db operations you could easily contain that to a small part of the code and stepping up to django would have felt like a huge step up in complexity. But I guess it really depends on what you're actually writing - your use case sounds a bit like "something like wordpress" from a "customer uses this" point, and mine were mostly "small REST API endpoint for something".
Small REST APIs are usually not very small because they hit the database to perform useful operations, must be tested etc. Furthermore a framework enforced common structure shortens the onboarding time for any developer regardless of the seniority.
I regularly end up having to
1. Either write my own code to query the db and build Ruby objects from the response and viceversa OR use ActiveRecord.
2. Same thing about managing the database schema. Either my own code or someone else's. So why not Rails' well tested one?
3. Organize the code base in some way that makes sense.
4. Write my own code to manage tests OR use rspec / capibara (OK, they are not part of a framework but they are a large dependency)
In the end I always regret I didn't use Rails from the beginning because I end up spending a lot of time doing useless takes. Keep in mind that I do that for my own projects in my free time. 99% of the times my customers decide what to use (Rails, Django, Phoenix.)