Marco_Weiss Limits are based on the following parameters:
MAX_QUERIES_PER_HOUR
for reads
MAX_UPDATES_PER_HOUR
for writes
MAX_CONNECTIONS_PER_HOUR
for max connections.
These are regulated by the server itself, all requests are logged and it's therefore easy to keep track of the real time data. Once either of these limits kicks in your connection will result in an error until enough time has passed to clear up a bit more of the hourly quota.
Of course, by updating the limits you'll instantly regain access to the higher limits. The containers themselves will also scale up as soon as needed.
There is no ETA for when the beta is over and due to low limits for now we wont ever charge databases created during beta, unless you choose to upgrade later.
Frederik_Madsen This is the same problem we were facing, databases that can't scale easily are prone to failures or may at least cause trouble. The cost for the end user would just be too high managing such solution at small scale. And we wouldn't be able to compete with the solutions already on the market.
As for "serverless", the offerings that exist are generally very costly, yet convenient and with the advantage of being billed per use. "Serverless" is also technically false advertising, because in the end there's always gonna be servers in the back-end no matter how the solution is implemented. With "containerized", we're trying to be as transparent as possible, because that's what it is we're dealing with here.
Prices are yet to be determined, but do expect low cost compared to managed dedicated database servers, as well as un-managed self hosted environments built for maximum performance.