> I am not sure whether not having control over upgrades is a feature or a bug.
I think different people will have different answers to that question depending on their circumstances and abilities. Some want full operational control over everything, and others would much rather just have a database to use that's always upgraded, monitored, backed up, and so on. Our target market is the latter group.
Bear in mind that doing your own sysadmin work for your database is not free. Besides the direct costs of paying someone to do the upgrades, test the backups, and so on, it diverts human time and attention away from other endeavors. Human time is a tech company's greatest asset, and we are betting that a significant number of people are prepared to pay someone to handle all of that for them, so they can focus on their core business.
> Optimized for what ? Any non-trivial database is going to require tuning, for which there is no one best way - only custom choices.
Yes, you are absolutely right. Out of the box, our databases are tuned for what we perceive to be a "generic average web app workload" on the underlying host type that they use. I realize this is rather vague and does not cover many use cases.
Use case specific tuning is definitely on the feature list for future versions. Do you have any insight on how that could be implemented in such a way that it'd be a good value for you? In other words, can the broad array of custom choices be reduced to any smaller set of useful patterns?
I'd like to see distinctive feature list (and not the underlying cloud provider's features). How is this better than spinning up a pg instance on AWS RDS? Heroku Postgresql? Or if you're running a Rails app, pointing Cloud 66 at your repo and your Digital Ocean account, and getting a full stack built?
Thanks for the feedback. I will be revising the features list shortly to (hopefully) make the unique value proposition clearer based on this and other feedback from this thread.
Heroku suffers from all of the same technical shortcomings listed there since it is also hosted on Amazon EC2 and also runs on EBS network drives. Beyond that, while I like Heroku's simplicity and tooling, Heroku is frankly insanely expensive for what you get at all but the lowest pricing tiers. They use this as part of a vendor lock-in based user retention strategy. That is, they make it rather painful to ever get your data out of their system once it's on. At the free / low tiers, it seems like a great deal. Then, when your app actually takes off, they ramp up the price very quickly, betting that most people will just pay (because it means their app is becoming successful) rather than bother with jumping through the hoops they set up to get your data out of their system.
We believe that the superior long-term business strategy is to build customer trust and develop a reputation for superior customer treatment: your data is yours, and you can take it anywhere you like. We aren't going to try to lock you in, we won't threaten to incur downtime for your app if you leave, and we believe our prices are much fairer.
As for running your own Postgres instance, the non-trivial burden of conducting and testing reliable offsite backups, upgrading Postgres, patching the operating system for security holes and monitoring it for intrusions, and doing other general sysadmin work is then entirely on you. Some people want that level of control, which is fine, but it's not free. Our feedback so far indicates that a significant number of Postgres users would much rather pay for that and focus their time and energy on their core app.
A feature list would be nice. One reason you might want to avoid Amazon could be that you're competing with Amazons other business, so using their AWS would be a bit weird, not that I think Amazon really care.
Option and competition is good, and being able to buy into a well managed hosted Postgresql is really appealing if you don't have the resources to manage a database installation yourself. Currently the alternatives for Postgresql is really expensive. EnterpriseDB have a nice offering, but it's really expensive.
All this of cause assumes that databaselabs.io isn't just two guys with a server in their basement.
So... reactively you get tired of seeing disk io so you make indexes for me, and/or I'm not allowed to define my own indexes, or are you talking more server level like shared_buffers and work_mem? Or a third level like hardware level where I'm using more CPU so you give some to me and take it away from an instance not using it so much?
Just saying I'd see a difference in language like "schema level" vs "server level" vs hardware level.
I'm indecisive about this. As a gamble, should I use you guys and pay a little more for someone else to worry about differing levels of management and tuning, vs spin up my own and worry about it myself...
Hi, Database Labs founder here. That phrase could be a little clearer, I agree. I'm going to update the site soon to incorporate the feedback I've gotten.
What we mean is that the Postgres system itself is "server / OS level" management. We set up a reasonable set of defaults for a generic workload per server type, and you get superuser access to the Postgres server to do what you like with in terms of internal structure (schema, indices, users/roles, and so on.)
We handle backups, OS upgrades, Postgres upgrades, monitoring, OS-level security, firewalling, intrusion detection, and other sysadmin-like stuff. We are on call 24 hours a day to deal with the issues that will inevitably arise, and we proactively work to minimize the frequency with which they happen.
The value proposition lies in how you want to spend your time. Our feedback so far indicates that a significant number of people would rather pay someone to handle all of the sysadmin chores and focus their time on their core app.
Thanks for the feedback. I'll be updating the page soon to try to make the value proposition clearer.
My assumption would be server-level management similar to RDS and Heroku. Since they run on DigitalOcean, I don't think they have much control over the hardware. Managed at the database/schema/table/etc level does not seem plausible as that would defeat the purpose of a product like this.
I don't see anything here about replication or even backups. To me that is why I'd use hosted Postgres. RDS gives me multi-AZ failover but no access to the slave for scaling read-only queries, no way to configure pushing WAL archives, etc. (They do offer slave access for MySQL, so hopefully this is just a matter of time.)
Going up against RDS, Heroku Postgres, and the dozens of existing hosted Postgres vendors is a tough market. You have to offer more than just `apt-get install` and some tweaks to postgresql.conf!
Hello, Database Labs founder here. As others mentioned, we do continuous offsite backups (to Amazon S3) via WAL logging, as well as daily snapshots. I'll be updating the features list soon based on feedback we've gotten here to make that more visible.
We do have replication setups, but it's currently only available via manual operation / support ticket. We'll be adding controls for that to the user interface soon.
Besides the 'apt-get install' and a few config tweaks, we are offering a managed service. You are getting a professional operational staff on call 24 hours a day to ensure that your database server is always running, always has the latest security patches, that the backups always happen on schedule, and so on.
I think the ongoing value of old fashioned system administration is easy to overlook until you wake up one day and find it crashed or you were hacked at 2 AM and they have a pile of angry customers!
It's easy to see the value in a "positive result" proposition -- pay and you get something. It's a little harder to see the value in a "negative results" proposition -- you are paying so that something does NOT happen; for proactive work to ensure that your database doesn't die horribly and unexpectedly. If all goes well, it just works.
We are getting good feedback from people who have either done sysadmin stuff and know firsthand how much work goes into tending servers, or who have neglected to do it and then been burned at an inopportune moment by a server failure. These people are usually quite willing to pay for someone else to do it. The value proposition here is that we will handle all that for you.
I'll offer some questions I'd be asking if I were on your board of directors. I hope they are helpful as you grow.
- It looks like your model assumes a base 50% materials cost. (I'm assuming you're storing WALs in customer's S3 accounts, not yours.) After adding staff and other costs, how likely is this to reach break-even?
- And at what scale?
- How do you differentiate if/when Digital Ocean starts moving up the stack (assuming they will eventually want to move into higher-margin products a la AWS)?
This looks nice! As others have mentioned, more details on what exactly "fully managed" and "optimized" entails. I don't think the pricing is quite worth it just for removing the server provisioning aspect (because others do that for cheaper), but if you can automagically make my queries run faster without me needing to think about it, then you're onto something. If that's the selling point, I'd love to be able to find more details about it!
I'm developing an application that uses lots of little blobs of JSON to represent objects. (Who isn't?)
I'm going to put them into a database, probably Postgres, maybe also Mongo or something like that.
I'd like to keep the important JSON objects checked into git, either with the source code they belong to, or as a separate repo. It needs to export and import them all one to a file, as normalized pretty printed JSON, so git can track and merge changes line by line, and recreate the entire system including source code and matching data at a later point in time. Not everything in the database needs to be tracked in git, just the important bits of JSON that need to be kept in sync with the code.
What I want to avoid is having a huge monolithic database backed up in a different way and on a different schedule as the source code is being tracked, so the important JSON data is mixed up with bulky transient tables in SQL dumps, so it's slow and tedious to recreate the source code with the matching data. What I want is for it to be easy to track and merge and revert changes to that important JSON data, and to back up the data in lock step with the source code that depends on it.
Somebody must have tried something like this before -- is it a crazy idea, or is there a better approach, or some system that tackles this problem already? Thanks in advance!
How much data are we talking about? If it is small and static, then it can probably just be stored in git. If it is dynamic and/or large, the typical solution is to have a separate table with diffs and timestamps. You could even add the git checksum since you want it synced with git.
I would love to be more helpful. If you want to talk further about your particular problem and possible solutions, please contact me: rpedela at datalanche.com
Taking a look at it, I would do something similar to what compose.io does with its pricing model (https://www.compose.io/pricing/). Giving out a free tier, gives the best introduction to something like a database as a service.
It was what brought me over to a paid plan at compose.
What kind of reliability/fault tolerance guarantees do you offer? Do you implement multi-master clusters for postgres and offer a simple interface? Or do you just install Postgres on a machine for someone?
We offer 99.99% uptime, with refunds for outages beyond that.
We can set up read replicas manually for you at this stage; a user interface control for that is in the works. Multi-master is not available yet. If many people want that, we'll add it.
What we do is a bit more than "just" installing Postgres on a machine. We manage it for you as a system. By that I mean we do the sorts of boring operational sysadmin tasks that are often overlooked and not accounted for when one considers running a server: we do uptime monitoring, backups, firewalls, operating system and Postgres patches, security / intrusion detection, and so on; and we have staff on call 24 hours a day to handle the inevitable problems.
All that stuff costs time and money, and we've found that many people prefer to pay someone to handle it all so they can focus their time on building out their core business rather than on learning to be sysadmins.
How much configuration changes do we have access to behind the scenes? Any chance the pg_hba.conf is available to the owner? Similarly, do we have access to create additional roles/users?
You get superuser access to the Postgres server, so administratively you can do anything at all that can be done from an interactive psql session - create/delete/update databases, roles/users, privileges, and so on.
We don't currently have any way for end users to tweak pg_hba.conf or other backend config files. We open up port 5432 for SSL-encrypted connections from psql or any other Postgres-compatible software. Does that cover the cases where you'd want to modify pg_hba.conf?
The smallest thing is $10/month, that's way too expensive.
I think you might get more traction if you did more to explain exactly what someone would be getting that price BEFORE you showed them the price.
Right now, the feature area (below the pricing), is so sparse and all over the place that it's a chore to read.
It seems like you're going to completely manage the database side? if so, then maybe you should say something like "we'll be your database guys". If it's not that, and it's just hosting the database/making sure it's up then have some sort of message specific to that?
I think $10/month is pretty cheap, assuming the service is good.
We're so use to getting a "free tier" or paying for some obscure gigabyte-hour / dingo-dyno tier. I like that these guys are upfront with that you need to pay, and having easy to understand prices.
So basically you are clearly specifying you are using DigitalOcean to host it, and just multiply the price by 2 :/.
I don't know if that would attract someone, it doesn't work for me. Not enough features for twice the price. I would advice only a small increase (+10% or so).
Quick general question:
I have a server in Montreal. My server hosting doesn't have SSDs for cheap. For a semi-big database (2gb), is it better for me to get a DigitalOcean with SSD in New York? Would that improve my database, or will the ping slow it down too much. (in my example the ping would be of about 23ms)
If the whole database is 2GB, can you get a server big enough to have all your data in memory, or at least the hot part of your data? That would be better.
I'll answer my question. They tackle this problem by advertising as such:
"Lives in DigitalOcean, near your app"
So basically, for optimal performance, my app should be hosted on DigitalOcean.
[+] [-] liotier|11 years ago|reply
I am not sure whether not having control over upgrades is a feature or a bug.
> We set up and maintain an optimized Postgres instance
Optimized for what ? Any non-trivial database is going to require tuning, for which there is no one best way - only custom choices.
[+] [-] pjlegato|11 years ago|reply
> I am not sure whether not having control over upgrades is a feature or a bug.
I think different people will have different answers to that question depending on their circumstances and abilities. Some want full operational control over everything, and others would much rather just have a database to use that's always upgraded, monitored, backed up, and so on. Our target market is the latter group.
Bear in mind that doing your own sysadmin work for your database is not free. Besides the direct costs of paying someone to do the upgrades, test the backups, and so on, it diverts human time and attention away from other endeavors. Human time is a tech company's greatest asset, and we are betting that a significant number of people are prepared to pay someone to handle all of that for them, so they can focus on their core business.
> Optimized for what ? Any non-trivial database is going to require tuning, for which there is no one best way - only custom choices.
Yes, you are absolutely right. Out of the box, our databases are tuned for what we perceive to be a "generic average web app workload" on the underlying host type that they use. I realize this is rather vague and does not cover many use cases.
Use case specific tuning is definitely on the feature list for future versions. Do you have any insight on how that could be implemented in such a way that it'd be a good value for you? In other words, can the broad array of custom choices be reduced to any smaller set of useful patterns?
[+] [-] tschellenbach|11 years ago|reply
that being said, don't know how this is any different than Amazon RDS
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] bdcravens|11 years ago|reply
[+] [-] pjlegato|11 years ago|reply
Thanks for the feedback. I will be revising the features list shortly to (hopefully) make the unique value proposition clearer based on this and other feedback from this thread.
I wrote of some key advantages over RDS at https://news.ycombinator.com/item?id=8483711 , which I'll soon be incorporating into the website.
Heroku suffers from all of the same technical shortcomings listed there since it is also hosted on Amazon EC2 and also runs on EBS network drives. Beyond that, while I like Heroku's simplicity and tooling, Heroku is frankly insanely expensive for what you get at all but the lowest pricing tiers. They use this as part of a vendor lock-in based user retention strategy. That is, they make it rather painful to ever get your data out of their system once it's on. At the free / low tiers, it seems like a great deal. Then, when your app actually takes off, they ramp up the price very quickly, betting that most people will just pay (because it means their app is becoming successful) rather than bother with jumping through the hoops they set up to get your data out of their system.
We believe that the superior long-term business strategy is to build customer trust and develop a reputation for superior customer treatment: your data is yours, and you can take it anywhere you like. We aren't going to try to lock you in, we won't threaten to incur downtime for your app if you leave, and we believe our prices are much fairer.
As for running your own Postgres instance, the non-trivial burden of conducting and testing reliable offsite backups, upgrading Postgres, patching the operating system for security holes and monitoring it for intrusions, and doing other general sysadmin work is then entirely on you. Some people want that level of control, which is fine, but it's not free. Our feedback so far indicates that a significant number of Postgres users would much rather pay for that and focus their time and energy on their core app.
[+] [-] mrweasel|11 years ago|reply
Option and competition is good, and being able to buy into a well managed hosted Postgresql is really appealing if you don't have the resources to manage a database installation yourself. Currently the alternatives for Postgresql is really expensive. EnterpriseDB have a nice offering, but it's really expensive.
All this of cause assumes that databaselabs.io isn't just two guys with a server in their basement.
[+] [-] VLM|11 years ago|reply
"All databases are fully managed and tuned by us"
So... reactively you get tired of seeing disk io so you make indexes for me, and/or I'm not allowed to define my own indexes, or are you talking more server level like shared_buffers and work_mem? Or a third level like hardware level where I'm using more CPU so you give some to me and take it away from an instance not using it so much?
Just saying I'd see a difference in language like "schema level" vs "server level" vs hardware level.
I'm indecisive about this. As a gamble, should I use you guys and pay a little more for someone else to worry about differing levels of management and tuning, vs spin up my own and worry about it myself...
[+] [-] pjlegato|11 years ago|reply
What we mean is that the Postgres system itself is "server / OS level" management. We set up a reasonable set of defaults for a generic workload per server type, and you get superuser access to the Postgres server to do what you like with in terms of internal structure (schema, indices, users/roles, and so on.)
We handle backups, OS upgrades, Postgres upgrades, monitoring, OS-level security, firewalling, intrusion detection, and other sysadmin-like stuff. We are on call 24 hours a day to deal with the issues that will inevitably arise, and we proactively work to minimize the frequency with which they happen.
The value proposition lies in how you want to spend your time. Our feedback so far indicates that a significant number of people would rather pay someone to handle all of the sysadmin chores and focus their time on their core app.
Thanks for the feedback. I'll be updating the page soon to try to make the value proposition clearer.
[+] [-] rpedela|11 years ago|reply
[+] [-] pjungwir|11 years ago|reply
Going up against RDS, Heroku Postgres, and the dozens of existing hosted Postgres vendors is a tough market. You have to offer more than just `apt-get install` and some tweaks to postgresql.conf!
[+] [-] pjlegato|11 years ago|reply
We do have replication setups, but it's currently only available via manual operation / support ticket. We'll be adding controls for that to the user interface soon.
Besides the 'apt-get install' and a few config tweaks, we are offering a managed service. You are getting a professional operational staff on call 24 hours a day to ensure that your database server is always running, always has the latest security patches, that the backups always happen on schedule, and so on.
I think the ongoing value of old fashioned system administration is easy to overlook until you wake up one day and find it crashed or you were hacked at 2 AM and they have a pile of angry customers!
It's easy to see the value in a "positive result" proposition -- pay and you get something. It's a little harder to see the value in a "negative results" proposition -- you are paying so that something does NOT happen; for proactive work to ensure that your database doesn't die horribly and unexpectedly. If all goes well, it just works.
We are getting good feedback from people who have either done sysadmin stuff and know firsthand how much work goes into tending servers, or who have neglected to do it and then been burned at an inopportune moment by a server failure. These people are usually quite willing to pay for someone else to do it. The value proposition here is that we will handle all that for you.
[+] [-] glutamate|11 years ago|reply
[+] [-] thu|11 years ago|reply
[+] [-] runako|11 years ago|reply
I'll offer some questions I'd be asking if I were on your board of directors. I hope they are helpful as you grow.
- It looks like your model assumes a base 50% materials cost. (I'm assuming you're storing WALs in customer's S3 accounts, not yours.) After adding staff and other costs, how likely is this to reach break-even?
- And at what scale?
- How do you differentiate if/when Digital Ocean starts moving up the stack (assuming they will eventually want to move into higher-margin products a la AWS)?
[+] [-] sanderjd|11 years ago|reply
[+] [-] DonHopkins|11 years ago|reply
I'm developing an application that uses lots of little blobs of JSON to represent objects. (Who isn't?)
I'm going to put them into a database, probably Postgres, maybe also Mongo or something like that.
I'd like to keep the important JSON objects checked into git, either with the source code they belong to, or as a separate repo. It needs to export and import them all one to a file, as normalized pretty printed JSON, so git can track and merge changes line by line, and recreate the entire system including source code and matching data at a later point in time. Not everything in the database needs to be tracked in git, just the important bits of JSON that need to be kept in sync with the code.
What I want to avoid is having a huge monolithic database backed up in a different way and on a different schedule as the source code is being tracked, so the important JSON data is mixed up with bulky transient tables in SQL dumps, so it's slow and tedious to recreate the source code with the matching data. What I want is for it to be easy to track and merge and revert changes to that important JSON data, and to back up the data in lock step with the source code that depends on it.
Somebody must have tried something like this before -- is it a crazy idea, or is there a better approach, or some system that tackles this problem already? Thanks in advance!
[+] [-] rpedela|11 years ago|reply
I would love to be more helpful. If you want to talk further about your particular problem and possible solutions, please contact me: rpedela at datalanche.com
[+] [-] dvcc|11 years ago|reply
It was what brought me over to a paid plan at compose.
[+] [-] ceejayoz|11 years ago|reply
[+] [-] egmracer|11 years ago|reply
[+] [-] pjlegato|11 years ago|reply
We offer 99.99% uptime, with refunds for outages beyond that.
We can set up read replicas manually for you at this stage; a user interface control for that is in the works. Multi-master is not available yet. If many people want that, we'll add it.
What we do is a bit more than "just" installing Postgres on a machine. We manage it for you as a system. By that I mean we do the sorts of boring operational sysadmin tasks that are often overlooked and not accounted for when one considers running a server: we do uptime monitoring, backups, firewalls, operating system and Postgres patches, security / intrusion detection, and so on; and we have staff on call 24 hours a day to handle the inevitable problems.
All that stuff costs time and money, and we've found that many people prefer to pay someone to handle it all so they can focus their time on building out their core business rather than on learning to be sysadmins.
[+] [-] abstrct|11 years ago|reply
[+] [-] pjlegato|11 years ago|reply
You get superuser access to the Postgres server, so administratively you can do anything at all that can be done from an interactive psql session - create/delete/update databases, roles/users, privileges, and so on.
We don't currently have any way for end users to tweak pg_hba.conf or other backend config files. We open up port 5432 for SSL-encrypted connections from psql or any other Postgres-compatible software. Does that cover the cases where you'd want to modify pg_hba.conf?
[+] [-] hardwaresofton|11 years ago|reply
I think you might get more traction if you did more to explain exactly what someone would be getting that price BEFORE you showed them the price.
Right now, the feature area (below the pricing), is so sparse and all over the place that it's a chore to read.
It seems like you're going to completely manage the database side? if so, then maybe you should say something like "we'll be your database guys". If it's not that, and it's just hosting the database/making sure it's up then have some sort of message specific to that?
[+] [-] mrweasel|11 years ago|reply
We're so use to getting a "free tier" or paying for some obscure gigabyte-hour / dingo-dyno tier. I like that these guys are upfront with that you need to pay, and having easy to understand prices.
[+] [-] __xtrimsky|11 years ago|reply
I don't know if that would attract someone, it doesn't work for me. Not enough features for twice the price. I would advice only a small increase (+10% or so).
Quick general question:
I have a server in Montreal. My server hosting doesn't have SSDs for cheap. For a semi-big database (2gb), is it better for me to get a DigitalOcean with SSD in New York? Would that improve my database, or will the ping slow it down too much. (in my example the ping would be of about 23ms)
[+] [-] thu|11 years ago|reply
Having about 10,000 customers at that price point asking "quick general question" to gain a ridiculous salary ?
[+] [-] icot|11 years ago|reply
[+] [-] rayanm|11 years ago|reply
[+] [-] rayanm|11 years ago|reply
[+] [-] SteventM8|11 years ago|reply