7 ms·

> 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 hav

by 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.
- pjlegato 12y ago
  Hello, Database Labs founder here. 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.
  - yangyang 12y ago
    Are the SSDs at Digital Ocean enterprise grade and RAIDed? They won't corrupt data under power loss etc? Bearing in mind you're probably using asynchronous replication, people you can't rely on that for durability; people will expect that once it's committed, it's on on (at least 2) disks.
    - misframer 12y ago
      I think they use RAID 5.
  - pjungwir 12y ago
    Using an SSD for your database is tempting, but please be aware you must use an SSD that can flush to disk in case of power loss. You should read here: http://www.postgresql.org/docs/9.3/static/wal-reliability.html 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@developer.localdomain http://www.postgresql.org/message-id/1396467425.2481.2.camel... and http://www.postgresql.org/message-id/50A34426.5020304@strategicdata.com.au 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.
pjlegato 12y ago
Hi, Database Labs founder here. > 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?
- fleitz 12y ago
  Most broadly, write heavy and read heavy, and then OLTP vs. OLAP. 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.
  - pjlegato 12y ago
    Thanks, that seems like a good starting point.
- yangyang 12y ago
  Do clients get Postgres superuser access?
  - 12y ago
deleted 12y ago
[deleted]

by liotier 12y ago

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.
pjlegato 12y ago
Hello, Database Labs founder here. 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.
- yangyang 12y ago
  Are the SSDs at Digital Ocean enterprise grade and RAIDed? They won't corrupt data under power loss etc? Bearing in mind you're probably using asynchronous replication, people you can't rely on that for durability; people will expect that once it's committed, it's on on (at least 2) disks.
  - misframer 12y ago
    I think they use RAID 5.
- pjungwir 12y ago
  Using an SSD for your database is tempting, but please be aware you must use an SSD that can flush to disk in case of power loss. You should read here: http://www.postgresql.org/docs/9.3/static/wal-reliability.html 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@developer.localdomain http://www.postgresql.org/message-id/1396467425.2481.2.camel... and http://www.postgresql.org/message-id/50A34426.5020304@strategicdata.com.au 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.

pjlegato 12y ago

Hi, Database Labs founder here. > 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?

fleitz 12y ago
Most broadly, write heavy and read heavy, and then OLTP vs. OLAP. 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.
- pjlegato 12y ago
  Thanks, that seems like a good starting point.
yangyang 12y ago
Do clients get Postgres superuser access?
- 12y ago

deleted 12y ago

[deleted]