9 ms·

Show HN: Database Labs – Postgres as a Service

46 points by pjlegato 12y ago

ceejayoz 12y ago
If your ticket priorities are "highest" or "high", "high" is just "normal".
dvcc 12y ago
Taking a look at it, I would do something similar to what compose.io does with its pricing model (https://www.compose.io/pricing/ 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.
__xtrimsky 12y ago
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)
- icot 12y ago
  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.
  - __xtrimsky 12y ago
    It looks like a safe method is to make the innodb_buffer_pool_size a lot bigger, and it will in fact store all the db in memory. (Otherwise you need to set up a backup or a replication in case the server goes down) I'll play around with it, thanks!
- thu 12y ago
  I would love to learn what you would expect from a PostgreSQL as a Service offer that would cost $0.50/month on top of DO. Having about 10,000 customers at that price point asking "quick general question" to gain a ridiculous salary ?
hardwaresofton 12y ago
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?
- mrweasel 12y ago
  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.
  - pjlegato 12y ago
    Hi, Database Labs founder here. We indeed are very upfront and transparent -- no hidden costs, and no teaser free tier followed by a massive price jackup once you actually get any significant traction. 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.
    - hardwaresofton 12y ago
      Yeah so I didn't mean that you should sell it for free, but the issue here is that I an easily rent a VPS (and I do) with better specs for cheaper and it's not super clear exactly what you're offering on top outside of "VPSes to run database x" on.
bdcravens 12y ago
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?
- mrweasel 12y ago
  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.
  - exhilaration 12y ago
    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!
- pjlegato 12y ago
  Hello, Database Labs founder here. 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 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.
VLM 12y ago
What does this mean: "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...
- rpedela 12y ago
  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.
- pjlegato 12y ago
  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.
liotier 12y ago
> Yes, all databases are operationally managed by us. You never have to worry about maintaining the database or operating system. 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.
- tschellenbach 12y ago
  well actually default postgres config is pretty slugish, their defaults are surely better than any untuned pg instance that being said, don't know how this is any different than Amazon RDS
  - yid 12y ago
    > don't know how this is any different than Amazon RDS It runs on DigitalOcean, for one.
    - coolsunglasses 12y ago
      Not a plus.
      - yid 12y ago
        It is, if you're also running on DigitalOcean. Intra-DC latencies.
        deleted 12y ago
        [deleted]
        pjlegato 12y ago
        Hello, Database Labs founder here. DigitalOcean users are indeed a key market for us, for this reason. 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.
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 ago
    Thanks, I missed that!
  - yangyang 12y ago
    Replication 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 ago
      Hi, 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 ago
        That 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.
- 12y ago
sanderjd 12y ago
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!
abstrct 12y ago
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?
- pjlegato 12y ago
  Hi, Database Labs founder here. 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?
  - abstrct 12y ago
    Nice to hear about superuser. That's great. Unfortunately it doesn't sound like it will cover my use-case, but admittedly my scenario is a weird one (see http://schemaverse.com http://schemaverse.com). Either way, thanks for the response and best of luck with the service!
    - pjlegato 12y ago
      Er. Wow, that's a pretty awesome idea! 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?
      - abstrct 12y ago
        Thanks! Come try it out sometime :D You clearly have an equal love for postgres. 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.
DonHopkins 12y ago
I have a question for database wizards! 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 12y ago
  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
egmracer 12y ago
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?
- pjlegato 12y ago
  Hi, Database Labs founder here. 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.
  - deleted 12y ago
    [deleted]
runako 12y ago
Congrats on your launch! 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)?
rayanm 12y ago
Wouldn't be better to host a web application and the database on the same server for better performance?
- rayanm 12y ago
  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.
SteventM8 12y ago
does it have the ability to restrict access from specific IP's ?

46 points by pjlegato 12y ago

If your ticket priorities are "highest" or "high", "high" is just "normal".

dvcc 12y ago

Taking a look at it, I would do something similar to what compose.io does with its pricing model (https://www.compose.io/pricing/ 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.

__xtrimsky 12y ago

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)

icot 12y ago
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.
- __xtrimsky 12y ago
  It looks like a safe method is to make the innodb_buffer_pool_size a lot bigger, and it will in fact store all the db in memory. (Otherwise you need to set up a backup or a replication in case the server goes down) I'll play around with it, thanks!
thu 12y ago
I would love to learn what you would expect from a PostgreSQL as a Service offer that would cost $0.50/month on top of DO. Having about 10,000 customers at that price point asking "quick general question" to gain a ridiculous salary ?

hardwaresofton 12y ago

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?

mrweasel 12y ago
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.
- pjlegato 12y ago
  Hi, Database Labs founder here. We indeed are very upfront and transparent -- no hidden costs, and no teaser free tier followed by a massive price jackup once you actually get any significant traction. 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.
  - hardwaresofton 12y ago
    Yeah so I didn't mean that you should sell it for free, but the issue here is that I an easily rent a VPS (and I do) with better specs for cheaper and it's not super clear exactly what you're offering on top outside of "VPSes to run database x" on.

bdcravens 12y ago

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?

mrweasel 12y ago
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.
- exhilaration 12y ago
  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!
pjlegato 12y ago
Hello, Database Labs founder here. 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 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.

VLM 12y ago

What does this mean: "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...

rpedela 12y ago
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.
pjlegato 12y ago
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.

liotier 12y ago

> Yes, all databases are operationally managed by us. You never have to worry about maintaining the database or operating system. 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.

tschellenbach 12y ago
well actually default postgres config is pretty slugish, their defaults are surely better than any untuned pg instance that being said, don't know how this is any different than Amazon RDS
- yid 12y ago
  > don't know how this is any different than Amazon RDS It runs on DigitalOcean, for one.
  - coolsunglasses 12y ago
    Not a plus.
    - yid 12y ago
      It is, if you're also running on DigitalOcean. Intra-DC latencies.
      - deleted 12y ago
        [deleted]
      - pjlegato 12y ago
        Hello, Database Labs founder here. DigitalOcean users are indeed a key market for us, for this reason. 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.

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 ago
  Thanks, I missed that!
- yangyang 12y ago
  Replication 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 ago
    Hi, 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 ago
      That 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.
12y ago

sanderjd 12y ago

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!

abstrct 12y ago

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?

pjlegato 12y ago
Hi, Database Labs founder here. 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?
- abstrct 12y ago
  Nice to hear about superuser. That's great. Unfortunately it doesn't sound like it will cover my use-case, but admittedly my scenario is a weird one (see http://schemaverse.com http://schemaverse.com). Either way, thanks for the response and best of luck with the service!
  - pjlegato 12y ago
    Er. Wow, that's a pretty awesome idea! 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?
    - abstrct 12y ago
      Thanks! Come try it out sometime :D You clearly have an equal love for postgres. 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.

DonHopkins 12y ago

I have a question for database wizards! 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 12y ago
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

egmracer 12y ago

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?

pjlegato 12y ago
Hi, Database Labs founder here. 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.
- deleted 12y ago
  [deleted]

runako 12y ago

Congrats on your launch! 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)?

rayanm 12y ago

Wouldn't be better to host a web application and the database on the same server for better performance?

rayanm 12y ago
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.

SteventM8 12y ago

does it have the ability to restrict access from specific IP's ?