[Feature]: Added postgres to gh compose for production use

[aybruhm]

Description

This PR enhances the gh compose configuration for production use by introducing PostgreSQL and PgAdmin services. Additionally, it adds the necessary database source configuration to make possible for data migration from MongoDB to PostgreSQL.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
agenta	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 9, 2024 8:56am

[mmabrouk]

I see that the docker compose now includes both postgres and mongodb. I think this is not a sustainable solution since at some point we would want to remove mongodb. Instead what I would suggest is having too docker-composes the normal one, and one special for the migration. I would also think we should have a note in the documentation on how to do in the case of using gh

[aybruhm]

I see that the docker compose now includes both postgres and mongodb. I think this is not a sustainable solution since at some point we would want to remove mongodb. Instead what I would suggest is having too docker-composes the normal one, and one special for the migration. I would also think we should have a note in the documentation on how to do in the case of using gh

I'm not sure if I understand you completely. From what I gather, we plan to phase out MongoDB at some point. This would require us to notify our users through all available channels (newsletter, documentation, Slack) that we'll be removing MongoDB from our current compose files.

Why do we need a separate compose file for the migration? Won't we essentially have the same services as in the default OSS compose?

[mmabrouk]

I see that the docker compose now includes both postgres and mongodb. I think this is not a sustainable solution since at some point we would want to remove mongodb. Instead what I would suggest is having too docker-composes the normal one, and one special for the migration. I would also think we should have a note in the documentation on how to do in the case of using gh

I'm not sure if I understand you completely. From what I gather, we plan to phase out MongoDB at some point. This would require us to notify our users through all available channels (newsletter, documentation, Slack) that we'll be removing MongoDB from our current compose files.

Why do we need a separate compose file for the migration? Won't we essentially have the same services as in the default OSS compose?

Because the current docker-compose.gh contains both postgres and mongodb. However we are not using mongodb at all in OSS. So, the only reason we have this is to allow the migration.

So, basically you are saying we keep the docker composes as is right now (with the two services running in parallel), and then in v0.20, we remove mongodb, and then if someone wants to migrate, they need to go back to the release v0.19, and use that docker compose to migrate. Right?

[aybruhm]

So, basically you are saying we keep the docker composes as is right now (with the two services running in parallel), and then in v0.20, we remove mongodb, and then if someone wants to migrate, they need to go back to the release v0.19, and use that docker compose to migrate. Right?

Yes. In addition to that, we could also update the Postgres migration documentation to have users stop (and remove) the MongoDB container once they confirm that the migration was successful and their data is intact.