Ddev: Allow omitting DB container

[maddy2101]

Is your feature request related to a problem? Please describe.
Not really a problem, just ecological and performance related concerns. I'd like not to boot up any database, if my project doesn't call for one.

Describe the solution you'd like
A config option, that allows to omit the configuration and creation of a DB container.

[rfay]

Could you please say more about the environment in which you don't need a database please?

[t3easy]

TYPO3 with SQLite Database will not need a mariadb container.

[jfastnacht]

@maddy2101 Not a config option, but I asked how to do that on Stack Overflow before: https://stackoverflow.com/questions/54252928/running-ddev-without-database

Just in case you need a solution until the issue is solved.

[rfay]

Just a note about sqlite3: My own experience trying to use it in a multiuser environment with Drupal was dismal, not recommended. Hoping for better with TYPO3!

[lolli42]

+1 to this: I'm using ddev to run TYPO3 and symfony projects. Both run fine with sqlite, and some symfony projects don't even need a db at all. In those cases the db container is unused complexity. It would be great if it could be turned off by allowing 'db' as value for 'omit_containers' config option.

[mglaman]

Chiming in: https://contribkanban.com/ is D8 and run on SQLite for ~1 year without problems.

[rfay]

It's not too terribly hard to omit the db container. The thing that gets more difficult is re-doing the automatic settings.ddev.php generation and such. And adding new config that tells it that stuff, etc.

[Lefaux]

I wonder if the scope is important.
I see several usecases described here.

a) The original request which is "My App simply does not need a database".
b) The requests in the sense of "well, I can run project types other than 'PHP' like Drupal or TYPO3 with SQLite (insert random DB backend here)".

Case A seems to be the more prominent one to me.
I currently run 10+ ddev projects based on symfony and none of them needs a DB container.

Case B seems a bit like getting out of ddev's original scope - making things easy for developers.
I guess we can all agree that the "sane" default for TYPO3 is a MariaDB (or MySQL) DB backend.
I could imagine the same being true for Wordpress and Drupal.

So while it's nice that you can run your CMS/App with SQlite or Postgres or Orcale or MSSQL in my opinion this gets out of hand. This is where I'd personally draw the line.
ddev does not offer a SQLite container, nor a Postgres or Oracle or whatever container.
Once you leave the trail ddev provides you with, you're on your own - which I think is a good thing, because you can do your own magic. But that's not ddev's job.
So I don't see it being ddev's duty to create configuration files for non-standard usecases.

[andrewfrench]

@Lefaux @rfay
This issue has been dormant for a while, but there were a few conversations at T3DD that lead me to believe this would be a worthwhile addition for many development workflows. There's definitely quite a bit of untangling necessary to make this work, but I'm going to start taking a look.

[rfay]

Yeah, this is labeled "prioritized" for that same reason. People want it. It's not too hard, it's just that there's start code and stuff that's explicit about the db container.

[rfay]

Let's make sure to solve the problem with leakage of omit_containers into project config.yaml when working on this, https://github.com/drud/ddev/issues/1456. If we could solve that in a general way, too, we could put more things in global_config.yaml.

[rfay]

For those of you who have been eager to get this, I'd love to have you try this out and see if it will meet your needs. The artifacts are posted at https://github.com/drud/ddev/pull/1819#issuecomment-526418925 - @Lefaux @lolli42 @maddy2101