Containerized databases now in public beta

The_Moose

Today, we are excited to announce the launch of containerized databases in public beta. This offering represents our first fully managed solution, aiming to address a gap between shared hosting and high-end managed databases on dedicated servers, which is frequently overlooked.

What is a containerized database
A containerized database is essentially a regular, ordinary database server running inside a container. The benefits of this approach include real-time scaling, horizontal scaling, and easy deployment of nodes.

Why is this solution needed
At some point, you might encounter a situation where your website outgrows shared hosting, but transitioning to the cloud with web-server instances, load balancers, and database servers remains prohibitively costly.

While a website can readily scale horizontally across multiple nodes, managing a database cluster of similar size entails significant effort. Typically, outsourcing this task proves to be quite expensive. This is where containerized databases comes in.

How is it billed
During the beta period, containerized databases will be provided free of charge. With no SLA or backups. Once the beta concludes, each database will incur charges based on reads, writes, and connections per hour. Real-time usage statistics can be monitored via the control panel. Additionally, there will be always-free units available per database.

Scaling
Usage-based billing enables you to reserve maximum reads, maximum writes, and maximum connections, forming the basis for the hourly cost of a single database. As a database grows larger, you can easily upgrade, and when fewer resources are required, you can scale down and pay less.

Manage with ease via API: https://api.99stack.com/docs/v1.3/#tag/Database

Security
Since all connections will be made remotely, containerized databases will necessitate TLS encryption. Currently, this is accomplished using self-signed certificates. You can download the certificate for your region from the control panel and install it in your application.

Regions and database types
We will begin by introducing Mariadb (MySQL compatible) in our E11 region located in Zurich, Switzerland. Initially, this will be the sole option available. However, as demand grows, we plan to support additional database types and expand to more E11 regions.

Feedback
As always with new features, please make sure to share your feedback with us and let us know how we can improve.

Marco_Weiss

Looks great, but I'm a bit confused on the limits, how is it calculated and what will it cost after the beta is over, and when is the beta over?

The_Moose

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.

Frederik_Madsen

If the price is right this do look promising. After looking into other providers offerings it's not uncommon to see "managed databases", which is usually just their $5 offering (same specs as here), but with half the performance and a ridiculous price of $15/mo. Or $30/mo if you want "high availability" which is just two nodes in the same data center.

That I could build myself, but managed seems a lot more convenient nowadays with lower latency, at least on the same continent.

So this is a bit like "serverless" if I were to take a wild guess?

Frederik_Madsen

The_Moose Thank you for clarifying. 👍️

Kenneth_Crayton

Love it, and sorry for asking about future pricing that may not have been determined yet. But I am very curious regarding the "free quota" and usage based billing here as I haven't seen any mention on storage cost.

Let's assume that I have a development environment which I only use one or two times per week, will it be possible to scale down to within the "free quota" when I'm not using it, and scale up by a lot on the day I need access to a big database, and only pay for the reads and writes during the hours of usage?

If so that would be awesome because it's a feature I really miss about existing server less offerings. Most of which charge at least $30 - $60/mo no matter how much or little I use them.

The_Moose

Kenneth_Crayton Memory and CPU cycles is always gonna cost a lot more than storage, for now we go for "fair use" and recommend beta databases to not exceed 10GB of data. It is however possible that storage will also have some cost in the future, similar to the price of block storage. That is if we see incredibly large databases holding multiple terabytes of data taking advantage of the current "free storage".

As for your scenario with the development server. Yes, that is the plan. Ability to spin nodes up and down and only pay for what you use. Hence a useful solution in the following scenarios:

Development were you only need access during limited time
Predictable load, which if your limits are adjusted properly will provide a low cost database.
Convenient scaling, instantly scale from zero to a large database during a peak, although this might cost a bit more during the peak compared to some alternative solutions.

Raccoons

Might regret this but I've already migrated my sites main database to one of the containers. Opted for the highest limits I could set of 500K reads, 100K writes and 500 connections. We have 800 unique visitors every day with 50K page view, not insanely big but a reasonably large site. So far everything works great.

Big shout-out to the monitoring system, so simple yet so responsive with incredibly useful information, my biggest fear before migration was the potential risk of running out of quota, but thanks to the good monitoring this won't be an issue.

Also nice to see that it's already in API, It seems relatively easy to build a monitoring script that checks usage every minute and upgrade when needed, I'm 100% sure any serverless offering that advertise "autoscaling" will buy way more resources than actually needed, overcharge and oversell. I hope that won't be the case here.

Orson_Deforest

Raccoons You're a brave raccoon 🙂 how's it going so far?

Frederik_Madsen

Raccoons I too am curious about this.

Raccoons

Alles gut so far, our web servers are in Amsterdam and our old database were hosted in Frankfurt, we get slightly better performance from Zürich. As for overall performance our site is now slightly faster too which is great. Particularly when loading the next chunk of images, that used to be slow, now it's instant which indicates improved connectivity to our database.

James_Morgan

The perfect competitor to databases on shared hosting. Switzerland is also a great starter location. As long as the price is right, this will be great.

AndrewLowrance

Isolated containers might be better, less waste of resources on logging and better control over resources actually used.

The_Moose

New shared databases will be temporary disabled as we're rebuilding the platform to operate inside isolated containers instead, limited only by assigned performance. This will not only provide better performance and security but also reduce the overhead caused by inefficient monitoring of individual queries which will reduce cost in the long run.

The way shared databases currently works would simply not reach the price target we reach for to remain as a self sustainable product offering.