All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Managed DB with BYOC
There have always been a few things I've hated about managed DB services.
- Vendor lock-in. I don't want to be stuck using Akamai's or Vultr's services and be vendor locked.
- Pricing. All vendors charge per GB. So even though the product is the same, the cost grows linearly with the amount of RAM you have not with adding new servers.
- Limitations. You're still stuck to one provider, your backups are stuck with them, and limited to how they perform.
As someone who was in the process of setting up four production services, I decided to work on my own DB management tool that supports BYOC. Conceptually, my though process was I could deploy across cloud vendors in a region and have a geographically distributed and non-vendor locked solution. I didn't want to use Docker or K8s. So I've gotten it to the point where I can now deploy and manage Postgres clusters on-site with HA or across regions with a DNS based failover and custom cross-datacenter private networks. This is good enough for my needs, but...
I was thinking of commercializing the product a bit. I'm currently rolling out support for additional databases and services (ValKey, Kafka, RabbitMQ, and more). It's likely still a few months away, but I thought I'd see if anyone had thoughts or feedback on something like this exists. One thing I'll just elaborate on: the goal is to make deploying complex databases as easy as clicking a few buttons. After that, the required monitoring (security + availability) is also handled. Alerts are generated and a GUI would theoretically enable you to handle any issues. We wouldn't force upgrades on users, but like blue-green upgrades are already supported. All of the standard features are there (for Postgres, everything else will need work plus the product needs proper testing + auto-deploy and some other stuff setup).
There are as many feasible security measures in-place as possible. All communication is using pub-priv key encryption, must occur on IP space I own, and there are a few other things I won't mention. But I've already locked this down pretty aggressively, will continue to lock it down further. 
There are huge limitations as we'd be entirely BYOC which means a few things users can edit the environment themselves which makes our job so much more complex. Additionally, users are not vendor locked to us. They could use us to deploy a complex cluster and then cancel their service immediately.
Using DigitalOcean as an example, a 3-node cluster is $45.68 a month for 1GB. If you want to do Postgres, there's a 2GB minimum so it's twice the price. My thought process was along the lines of $5/month per node (includes setup, advanced server resource and availability monitoring + alerts, and security maintenance). So $15 for the cluster + $18 for their 1GB VPS. That's $33 vs $45.68. If you doubled the size of each instance, you'd still only pay $15 a month + $36 a month for their 2GB VPS. That's less than half the price of their own managed service! Of course, you can also deploy single node instances and you can theoretically deploy them on ANY VPS from any provider, so your costs would be $5 a month + whatever idler you have.
So I was wondering what type of pricing you'd consider paying for a service like this? What billing practices you'd expect? Any thoughts, ideas, etc to make this commercially viable (i.e. - minimizing setup and quit if possible)? Open to all input, even if you think it's a bad idea!
Comments
It's a bad idea because you're leaving money on the table. That's the reason other companies don't do it.
I would buy it because I need it (PostgreSQL, Redis/Valkey, Clickhouse, Solr/Elasticsearch etc)
To be fair, the compromise would be on support. I would expect slower support than with a cloud vendor. I think that's where a lot of the cost comes from. But maybe I'm missing something.
ClickHouse is on the list. It's actually what I'm working on next because I need it to get the cluster for monitoring working
You can add extra pricing for better support like many companies do.
Doing any of them (PostgreSQL,Clickhouse,Solr/Elasticsearch) is very hard, so I would caution to start with only 1 (PostgreSQL IMO is the most popular).
Think replication, high availability, backups, PITR, multi-az, pgbouncer, etc etc etc.
https://elest.io/ was a company that posted here expecting to do what you're saying but they blew it by focusing on too many apps, not doing any of them correctly and expensive pricing.
In B2B, make them pay as much as you can, no matter the cost. But make them think they're saving money. For example, compare your cost to the price of another engineer - "only $5000 per year? What a steal!"
If one of their own engineers could do what your product does for less, don't tell them that.
No, I understand. Already doing all of that for Postgres, ValKey, ClickHouse but the ValKey and ClickHouse integrations aren't fully complete and require manual setup on some stuff. Plus a thorough testing suite.
I wouldn't be targeting B2B. Smaller companies, individuals, etc. The pricing will ultimately reflect the level of support provided. I think that is a big part of what you're paying for on a lot of these expensive products. I've built out a good chunk of it myself. It's a bit of a different beast to share with other people though since you won't be able to quickly fix the issues that occur, which I can just do myself since I have full control.
See what cloud66.com does and try to replicate for dbs/redis/solr. They don't provide good enough HA/backups/proxy/etc on their db hosting but their app hosting is good.
This is extremely helpful! Effectively a very similar product, but I think functionally very different (I need to see how advanced their failover + clustering is, because the one we have supports IP failover, read/write distribution, etc). I really appreciate the insight!! I don't love their approach, but I might have to play around with it
My focus has been more on specific single services than applications (like Pg: single DB, leader-replica with auto-IP failover, complex geo-distributed clustering and then supporting important plugins via API) but maybe as to your point, we need to have some application deployment built in. Definitely a good point to consider!
They have manual failover, weird backups, it's a bit hacky.
Sounds good to me.
You should NOT offer application deployment. There's plenty of that. I linked to clou66 as an example. Offering only db deployment should be enough IMO.
The problem: a small company or individual can just install postgres on our VPS. Yes, sometimes there's downtime but it's small so who cares. Plus we don't have much money to pay you. Why would I pay 5 bucks a month when I can get a VPS to run postgres for that much? The amount you'd have to charge to make it worthwhile for you, exceeds the amount that would make it not worthwhile for me.