I share the same PostgreSQL DB instance across 3 different Django production projects hosted and deployed to Heroku. When I install the same Django web app package for all 3, in the Admin Dashboard for any one project, when I toggle the “is_protected” feature switch to “Off”, that will remove the protective gateway for all three at the same time. That’s a problem. I need to continue to share one database across all three projects in prod but now need a solution to make sure settings for one project do not impact the others.
I partially understand the reason why: It has to do with the architecture of Heroku and Django and PostgreSQL which all work together in such a way that apps that are named the same, the DB migrations are shared because the rows in the DB table have the same names. While the behavior works as intended in theory, for my purposes I want to be able to set one option to On for two of projects while the other one I need toggled Off.
I suppose it is conceivable to lease a different PostgreSQL instance for each environment from Heroku, but I currently pay for 2 instances: One for staging ($5/mo) and the other for production ($5/mo). If instead I leased one DB instance for every environment, that would cost me $30/mo because I would need a staging as well as production instance for each of the 3 projects. That is costly, redundant, and wasteful, especially considering that my CMS blog content is pure text data which altogether takes up < 3MB of storage capacity where as the PostgreSQL instances are intended to house 20GB each. So I would be paying for an incredible quantity of storage (like 120GB for 6 instances) that I won’t use. I have ideas for building 1 or 2 more Django CMS projects which wouldn’t make sense to keep paying for more and more storage when it’s completely unnecessary.
I am open to alternatives and am happy to consider any other solutions which may be better/best practices for my text only CMS use-case.
Your projects are all using the same database, and so they all share the same data. So if you change the data in one project, it’s changed for all projects.
It’s possible you could make some changes to your code so that some things can be changed on a per-project basis using the Sites framework. But without knowing anything about your code it’s hard to be more specific.
You can try using Postgres schemas, where each project can have its own schema. There is no direct support for this in Django.
If you’re optimizing for costs, heroku is generally your worst choice.
If all of your content is pretty much static, consider switching to a static site generator approach. That may mean Django isn’t the right tool for the job or perhaps a django app for ssg will do the trick.
Yes, this Sites framework doc is exactly what I was referring to in my original post and gives me something to work worth.
@massover Optimizing for costs might involve a DigitalOcean / Linode VPS, the problem there is that setup and configuration is more granular, nuanced, and labor intensive. Heroku’s docs and PaaS model meet my use-case, is always up to date, and also will scale easily when my projects are ready for production traffic. The only issue was the absurd scenario I outlined original invlving sharing 6 (!) DB’s which I think pilgyfords introduced the solution I need to save all that money on Heroku.
My content is not static (it’s highly dynamic and on rotation) and Heroku is setup in a way to serve and protect my data.
Yes, and that’s what you have to weigh up - the monetary cost of Heroku, or the time cost of a VPS. Some people like running their own server, enjoy learning how to do it, have the time to do it, and don’t mind the potential stress of doing so. I’ve never liked any of that - I like making sites and writing code! The few extra $ is worth not having to think about setting up and maintaining a VPS for me.
It’s not an ideal solution, because every model that needs to have distinct objects per-site has to have an extra site property, and it makes your code very slightly more complicated,with a little more potential for error. But if the cost saving is worth it, I hope it works for you.