Is it possible to run Postgres (or any DB) with Google Cloud Run?

Question

1. Summarize the problem

Google Cloud Run advertises that it is "stateless containers". Is there a way to run anything at all, have it save state somewhere?

I want to run Postgres in a container, but only have it up on demand, spin up the PG container when there is a request made.

The same question goes for a container that will hold a REST API (web server), to connect to the PG container.

So when the web app (hosted on Firebase), makes a request to the REST API (container), it would spin up, and then the PG instance that gets queried from the REST api would spin up (or can simply put both DB , REST API in one container).

For a dev instance, I don't want something up 24x7x365 doing mostly nothing, just something that will spin up during development hours, but have a number of these, am the only OPS guy, want to automate it for developers, including myself and minimize billing.

Any best approach here would be appreciated.

2. Provide background including what you've already tried

I have created Docker containers and deployed to Cloud Run

3. Show some code

yum install buildah podman -y

4. Describe expected and actual results including any error messages

I am looking for a solution to minimize billing for a dev environment that will include hosting and a database/REST API (database has to be Postgres).

I'm looking for a stateful cloud run that will maintain the state of a database.

Answer 1

Cloud Run is not suitable for hosting a database. Server instances allocated for incoming requests to Cloud Run can come and go, and not all requests will go to the same instance, which means that not all clients will see the same data. That's the problem with "stateless containers".

If you want to use Cloud Run to provide database access, it would best be as a proxy to some other cloud-hosted database service. You might use to it host a REST API endpoint that accesses some other database service (for example: Cloud Firestore, Cloud SQL). But it doesn't make sense to host the database itself in your docker image, since those server instances can come and go unpredictably, destroying any database state stored in each instance.