Show HN: Database Labs – Postgres as a Service
databaselabs.io
databaselabs.io
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.
that being said, don't know how this is any different than Amazon RDS
It runs on DigitalOcean, for one.
Besides DigitalOcean users, if your app is in a reasonably well connected data center, in many scenarios the additional network latency incurred by traversing the network from your data center to DigitalOcean is going to be minimal compared to the speed gain you get by running your database on SSD drives rather than on spinning disks or Amazon EBS.
Yes, our defaults are way better than an out-of-the-box Postgres. That said, we are acutely aware that significant further tuning specific to a particular database's workload can deliver even better performance. We are investigating the best way to deliver this to a broad audience now. Do you have any suggestions?
Amazon RDS uses Elastic Block Store (EBS) as its disk. EBS is extremely slow relative to the SSD drives used at DigitalOcean. Worse, unless you buy very expensive provisioned IOPS, you are competing for network bandwidth with all other EC2 customers in the physical network segment where your RDS database is hosted every time you do a disk access. This means your database will randomly become very slow at peak load times, with no visibility and no way to control it other than spending a whole lot of money on provisioned IOPS.
We've also gotten good feedback from a number of customers who simply do not want to deal with the complexity of AWS. Our API is far simpler; we don't have security groups and so on. If you actually need all that complexity, that's fine, but many people don't.
Finally, RDS does not support read replicas for Postgres (at all); you are limited to one database server. We are currently setting up replicas manually as requested, and will be building them into the user interface in the near future.
http://www.postgresql.org/docs/9.3/static/wal-reliability.ht...
and also search the pgsql-general mailing list for the numerous discussions there about which SSDs are safe for Postgres and which aren't, e.g.
http://www.postgresql.org/message-id/1396467425.2481.2.camel...
and
http://www.postgresql.org/message-id/50A34426.5020304@strate...
Assuming DO is giving you the SSDs you need, you should include a FAQ reassuring customers about that.
We asked for and received written confirmation from Digital Ocean on this question. Currently, all of their newer hardware uses full Battery Back Up (BBU) and RAID on all SSD arrays. Data centers where you are guaranteed to be on a box with their newer hardware are: NYC3, LON1, and AMS3. These locations are supported in the Database Labs interface.
Digital Ocean's other data centers have a mix of hardware. All hardware at a minimum has dual redundant power supplies and hardware RAID with SSD drives, however, not all hardware has a BBU on the RAID card. While it is extremely unlikely that there will be a full power outage that overlaps with a write time on a database, it is possible. We recommend, if this is a concern for anyone, that deployments be restricted to NYC3, LON1, and AMS3.
We will be monitoring this issue with Digital Ocean, and will let everyone know as more of their centers are guaranteed to be SSD + RAID + BBU.
Thanks for the suggestion of documenting this on the web site, we will be adding some information about this in the near future.
"Amazon RDS now supports General Purpose (SSD) Storage You can now launch DB Instances that use General Purpose (SSD) storage, a new SSD-backed storage option for Amazon RDS"
> 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?
Implement them as sliders, people will think it's great that they can have custom tuning based on what percent read/write and OLTP/OLAP they think their workload is.
Users receive superuser on a blank slate Postgres, and they can do whatever they like within the already-running Postgres server -- create/delete/update databases, users/roles, privileges, and so on.
We are seeking users who don't want to worry about wal_levels and things like that -- users who just want a Postgres server to use, with the assurance that backups, OS patches, and so on are all taken care of for them.
There is of course set_config in 9.4 - superusers can then edit the config file through that (a superuser can overwrite any file the user running the server can write to anyway, but through more convoluted means).
I'd also like to know more about how superusers can overwrite files. Do you have a link?
[1] http://www.postgresql.org/docs/9.4/static/functions-admin.ht... [2] http://www.postgresql.org/docs/9.4/static/runtime-config-wal...
Regarding superusers overwriting files - COPY can write to anywhere on the filesystem. From the docs "COPY naming a file is only allowed to database superusers, since it allows reading or writing any file that the server has privileges to access." [3].
[1] http://www.postgresql.org/docs/9.4/static/sql-altersystem.ht...
[2] http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-...
[3] http://www.postgresql.org/docs/current/static/sql-copy.html
>> 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 [..]
Of course, it's very easy to say some nice-sounding words like that. The real evidence can only be demonstrated over time, after many successive trials, through building up an ongoing relationship of trust with our customers and repeatedly demonstrating that we make the right calls most of the time.
With regards to breaking Postgres changes specifically, they are rare and almost always announced well in advance, giving us ample time to message the users, prepare them, and manage the transition.
I see this stage of the database market as analogous to e-mail in the early 2000s. At the time, most people read e-mail delivered by a custom Sendmail, Postfix, or Outlook installation. Many felt that the numerous gritty details of running an e-mail server meant that every site needed its own mail daemon, customized to its particular needs.
There were a few email-as-a-service offerings like Hotmail, but many admins felt they were too limited for serious business use cases.
It turns out that most businesses actually just needed GMail -- a really well done email-as-a-service platform. Sure, there are still some places that really do need a custom e-mail setup, and they continue to use custom software. For 80% of all businesses, though, a Google Apps GMail account is more than adequate. They trust that GMail's admins will make the right call. We aim to do the same for databases.
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.
Or two guys with an AWS account!
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.
"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...
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.
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!
We do nightly snapshots plus ongoing continuous WAL logging, so yes, you can do point-in-time recovery to any moment in the retention window. The retention window is 14 days minimum, with longer windows available upon request.
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.
In my comment, I tried not to compare your service to DIY, which of course may work for me but not most. I'm comparing it to RDS and Heroku Postgres. There are definitely gaps you can fill, but you will have to start offering some more advanced features if you want to compete with such trusted players.
If you want to compete on price, there are already dozens of other companies offering low cost, low quality Postgres hosting. So I think your best shot is offering a high quality product.
Also depending on your goals it may be fine if your product earns you more dollars from consulting than from hosting. :-)
We've gone through the same process, too, and come to a somewhat different conclusion. :) We perceive a gap in the market -- as you mentioned, there are many low-end Postgres hosting places, and a few expensive high end places. All are lacking features that we (personally) want, too, in one way or another.
I think that, at least partially, it comes down to Amazon and Heroku having many other lines of business. Postgres is just not a major priority for them at all. By focusing entirely on Postgres and only Postgres, we can deliver a better experience.
Competing on price is a race to the bottom. I don't want to be wading into a commodity market trying to pick up a million $5 customers. I'd much rather go for the higher end segment where we deliver premium service and features for people who see the value in that and are willing to pay for it.
I'd love to chat with you sometime in more detail about the Postgres idea.. if you're ever in San Francisco, I'll gladly buy you a beer or a coffee!
No plans to visit the Bay Area right now, but maybe I'll be down for a conference some time. If you're ever in Portland, I'll do the buying. :-)
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)?
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!
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
It was what brought me over to a paid plan at compose.
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.
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?
Unfortunately it doesn't sound like it will cover my use-case, but admittedly my scenario is a weird one (see http://schemaverse.com).
Either way, thanks for the response and best of luck with the service!
You can create and update user roles without altering pg_hba.conf, which I think would let you run most of that. What's the case where you'd need to alter pg_hba.conf directly?
I asked because we have been considering ways for people to easily deploy their own instance of the game (likely for educational purposes). So I try to keep an eye open for new db services.
The technical reason for the requirement is that players connect from all over but the system also needs to be able to connect as each player - preferably without knowing their password. We normally handle this with a trust relationship between specific servers. Alternatively we could be using a superuser account and SET ROLE but that would require some other changes as well.
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?
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.
Free tiers also invite abuse by shady actors (spammers and so on) and tire-kickers who generate support load but don't ever actually buy anything, which we just don't have the resources to deal with yet, as a small company.
It seems so far that $10 is a reasonably low price point for trying it out that people are willing to give it a shot, and it filters out a lot of the bad actors.. maybe when we're larger, we'll revisit the free tier idea.
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)
(Otherwise you need to set up a backup or a replication in case the server goes down)
I'll play around with it, thanks!
Having about 10,000 customers at that price point asking "quick general question" to gain a ridiculous salary ?