4 ms·
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 slav
by pjungwir 12y ago
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!
- glutamate 12y ago> Fully backed up continuously, offsite, via WAL logging
- pjungwir 12y agoThanks, I missed that!
- yangyang 12y agoReplication and backup solve different problems. What if I accidentally drop a table and need last night's backup? Are they archiving the WALs too so you can do point-in-time recovery?
- pjlegato 12y agoHi, Database Labs founder here. 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.
- yangyang 12y agoThat sounds sensible, thanks; I'd misunderstood and thought you were doing continuous replication to another PG server, now I realise you're archiving WAL to S3.
- thu 12y agoThey do mention offsite backup using WAL shipping.
- pjlegato 12y agoHello, 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.
- pjungwir 12y agoThank you for your reply! Sorry if all I offered was criticism. I almost started your company last year with a buddy, so I've thought about it a lot. (We decided it was too risky that AWS would release Postgres RDS--and they did!) 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. :-)