Should we make crunchy the default postgres/postgis database of choice

[mishraomp]

currently the postgres/postgis database is a single pod, with backup container doing backup and restore(no s3 support)

moving to crunchy means, HA out of the box with connection pooling, backups and restores are all handled by operator with secondary backup and restore from OCIO object store.

for PR based deployments, same DB instance can be resued for multiple PRs with schema based approach, where schema is dropped after PR is merged.

[mishraomp]

@DerekRoberts @conbrad @franTarkenton @paulushcgcj thoughts?

[franTarkenton]

I kinda like the exiting lightweight database that comes with the quickstart. I feel like the extra overhead that comes with HA, is more than what is required for many of the small apps I have been involved with working on. I love that its supported. I suppose if we make it crunchy the default, that give me the option of just adjusting my config.

I'm also almost certain that the default (meager) quotas that are being handed out for namespaces might not be enough to support crunchy without adjustments.

over.... 😺

[mishraomp]

I kinda like the exiting lightweight database that comes with the quickstart. I feel like the extra overhead that comes with HA, is more than what is required for many of the small apps I have been involved with working on. I love that its supported. I suppose if we make it crunchy the default, that give me the option of just adjusting my config.

I'm also almost certain that the default (meager) quotas that are being handed out for namespaces might not be enough to support crunchy without adjustments.

over.... 😺

could not agree more, really great points, may be another option like different backends, for teams wanting HA and needing that kind of setup with lot more resource quotas.

[paulushcgcj]

I also prefer the more lightweight postgres but it wouldn't hurt to have a config for the HA version as an example in case someone needs it. Maybe in a separate Branch where people can see it In action.

[mishraomp]

thanks @paulushcgcj , should we have a forked repo qsos-crunchy @DerekRoberts @franTarkenton @paulushcgcj @conbrad

[conbrad]

thanks @paulushcgcj , should we have a forked repo qsos-crunchy @DerekRoberts @franTarkenton @paulushcgcj @conbrad

I like the idea of opting in to crunchydb, given the feedback further up the thread. My only concern with forking for crunchydb would be the possibility of all configurations being forked for... sets a precedent for combinatorial explosion. Wonder if a CLI setup tool for choosing the database would be better?

[mishraomp]

thanks @paulushcgcj , should we have a forked repo qsos-crunchy @DerekRoberts @franTarkenton @paulushcgcj @conbrad

I like the idea of opting in to crunchydb, given the feedback further up the thread. My only concern with forking for crunchydb would be the possibility of all configurations being forked for... sets a precedent for combinatorial explosion. Wonder if a CLI setup tool for choosing the database would be better?

yeah, agreed, we will start with forked repo as test bed as per @DerekRoberts and then see how to merge both of them into QSOS, with a setup CLI, as the github actions workflows will be little different since crunchy cant be deployed for each PR instance, and has to be managed with schemas for each PR.

[DerekRoberts]

Ideally we won't maintain a second repo for Crunchy. The plan is just to test and mess around for now. :) @conbrad