[AndrewDucker]

But you do have to specify CPU and memory and pay for those for having the database running - even if you're not calling it.

What I'd like is to pay for what I use when calls are being made. Providing an SQL interface as a service, rather than actually running a whole personally copy of a database.

[phonon]

Something like https://aws.amazon.com/blogs/aws/amazon-aurora-postgresql-se... ?

[AndrewDucker]

Yup, except that's got a cold start time of 25 seconds. So no use for a low usage system. (One, for instance, that gets used a couple of times a day, but really needs to be available when it is.)

[phonon]

https://dev.to/dvddpl/how-to-deal-with-aurora-serverless-col...

[AndrewDucker]

Yes, the way to avoid a cold start is to keep it constantly running. Which rather undoes the point of only being charged when you're using it.

[phonon]

Well, you can scale it 64x on demand...seems like a good tradeoff.

[AndrewDucker]

Oh yes - if you are operating at the middle to high end it's a great system.

But if you want "Read a tiny table once an hour, carry out a simple action in the circumstances are right" then paying for a database to be taking up a core 24/7 is not going to work for you.

So I wish it scaled down as well as up.

[trevyn]

Just out of curiosity, what would an acceptable cold start time be? I feel like there’s a SQLite + function-as-a-service opportunity here.

[AndrewDucker]

Near zero. If my data is only a few kB then an already running process should be able to read it from disk and read/write the data almost instantly. They should be working on a version of MySQL that can do this without spawning a whole new running instance on a whole new server.

[dewey]

Maybe that's more of a BigQuery use case then where you pay for usage?

[hendiatris]

Unfortunately it’s not a relational database, so no constraints or any of the other features.