5 ms·

OK a bit of topic, but just curious we are considering rolling Postgres hosted service that would support much large instances up 50TB much higher IOPS 1,000,00

by qaq 10y ago

OK a bit of topic, but just curious we are considering rolling Postgres hosted service that would support much large instances up 50TB much higher IOPS 1,000,000+ lower latency (infiniband vs ethernet SAN) pricing would be in line with AWS RDS +/- optional ElasticSearch integration optional change notification pub/sub Would you guys be interested/think such service is a good idea? Would appreciate to learn what you guys think?

audleman 10y ago
My 2 cents: you're promising a lot more for the same price which seems dubious. How are you going to beat the wholesaler? Even if you did I probably wouldn't use it. I don't want a 3rd party dependency on the most critical part of my infrastructure.
- qaq 10y ago
  The price would be comparable to AWS appropriate tear eg 6TB storage for a bit less (10-15%) then amazon's 6TB RDS option but with much better performance. I totally get your reluctance to rely on 3rd party, but the question is more for people who already do rely on 3rd party such as AWS or Azure.
  - erkkie 10y ago
    How are you imagining solving latency issues? Many people want their DB to be close to their appservers. edit: and if it's an hosted service, I'm assuming decent networking options (ipsec et al)?
    - jbrantly 10y ago
      Exactly. I want my app server and my db server to be as close as possible. That's why services like Compose and ElephantSQL offer just that. So then it comes down to performance/price (value) between RDS and those.
      - qaq 10y ago
        Latency will be higher. We are considering if we do go forward: a) Partnerships with smaller providers where there is an option to colocate equipment b) Colocating as close to as possible to targeted providers. The main thing we are trying to figure out - if there is a need for service that has significantly higher tears then what Azure, AWS offers.
        erkkie 10y ago
        I would imagine people who need either more AWS can supply (or cheaper) but cannot pay for it, and also haven't figured out how to run it themselves, to be a very limited set. Happy to be proven wrong though and curious about what you will find out :) Is there a way to keep in loop?
        qaq 10y ago
        The thing that is impractical to do on premise is "transparent scaling" say your load increases and you need a way bigger box that's the kind of problem the service can solve (take slave offline remount storage on a bigger box catchup on replication switch to slave repeat for former master). We are at the early stage just investigating if we should move forward so @andre1sk on twitter would prob the only place :)
  - askldfhjkasfhd 10y ago
    > I totally get your reluctance to rely on 3rd party, but the question is more for people who already do rely on 3rd party such as AWS or Azure. Just a little input: Amazon and Microsoft are well known companies. I (and my superiors) think they can support us. Your company that I haven't heard of is not. It may be dumb sounding, but I won't get in trouble if I used AWS and something went wrong. How could I have known? With an unknown company, if something goes wrong, it's on me because I selected that vendor. Stupid perhaps, but important to understand.
sandGorgon 10y ago
Dont go for IOPS , but price. Make sure that there is replication and fail over... people at this stage just want to make sure that their data isn't lost. Use cheap hardware like ovh - you can beat AWS on price. Plus, googling for "hosted postgresql" is still something that can be competed upon.
Rezo 10y ago
When it comes to data, trust is key. Think about it this way: OCZ has on paper SSDs that are simultaneously both faster and cheaper than, say, Intel. But I wouldn't put a OCZ drive into the lowest budged ricer gaming PC I could imagine (let's just say that have a bit of a reputation, to put it lightly), and I should be rightfully fired if I suggested putting one in a server. Yes, your service might be massively faster, but... at 10-15% cheaper? No way! Not until you've been running for years with a great reputation. Now, if you enter the managed database space and pull a Digital Ocean ($5-$40 pricing vs comparable EC2 at $80-$400 AND better raw performance on top), then you can essentially create a new market niche. That's my suggestion to focus on, because businesses who operate 50TB databases aren't looking to save a few dollars. But people who use DO, need a database to go with it that is both faster and cheaper than AWS. Honestly, performance ranks pretty low on the things I've found people look for when choosing a managed database service. You can serve a million users per day and average a whopping 12 IOPS, which might just about push a Raspberry Pi with sqlite slightly. Got more than a million users? Congrats, you now officially qualify to throw money at problems, the kind of problems RDS and Amazon loves to solve by injecting money.
- qaq 10y ago
  You do not have an option to host anything larger then 6TB on RDS. I guess what we are trying to figure out is if there is a need for service for people who have needs beyond those RDS is addressing.
  - yeukhon 10y ago
    Not only disk space, you are limited to just two nodes (one primary and one standby). Of course you can create read replica, but that if you are write intensive, you can end up consuming all of your pools.
    - merb 10y ago
      actually you would shard than, which of course is possible with rds aswell. since you mostly shard at the application level. there are some users that use extensions but I guess calling the support of aws will get these extension in your rds instances.
deleted 10y ago
[deleted]
adwf 10y ago
My priorities are: Reliability > Size ~= Price > Performance Reliability of a database is always no.1, without it, nothing else matters. So the customer must have enough access to the machine to setup replication and failover themselves (eg. using something like repmgr). Or have damn good guarantees that you're doing it well for them. ie. multiple replicas, verifiable backups, offsite backups, etc. Secondly is size. This is a major sticking point for me when looking at hosted postgres solutions - they're mostly for relatively small databases <1Tb or so. Closely in third is price. Even when you do find a service that provides a decent size like when RDS eventually went up to 6Tb (still not quite enough for me), the price they charge for it (and the ram) over buying dedicated iron is exorbitant. Given that 6-8Tb drives are mainstream now, it's a real head scratcher why they'll charge $750-1500/mth for a 6Tb drive that costs $250 outright. And then charge you for the IOPS on top of that... Even factoring in multiple redundant drives/replicas, SSD vs HDD, it's still very unfavourable. I can install 5 machines (at least) in a cluster for the price of 1 on RDS; giving me not just price savings, but my no.1 need - reliability. Finally performance. The number of high IOPS workloads out there is rather small. You're far more likely to have a high storage need with small IOPS, than high IOPS, smaller storage. Everyone overestimates the amount of traffic they'll get, and generally if you have an IOPS problem, it's better off fixed elsewhere in the app. Usually some bad code or ORM is thrashing the DB. Take a simple login DB as a thought experiment, just 10,000 IOPS is upto 864 million users logging in per day. Whereas the storage for that number of users, at a very generous 1Kb per user, is 864Gb. Size is way more important than IOPS. And if you've got that number of users, you've also got your own datacentre :) You might also run into the problem that the kind of organisations that need high storage + high iops are also the kind that wouldn't use the cloud for it in a million years (banks, high freq. traders, etc). In summary, I think the main thing that would attract me is high capacity storage for a decent price. Reliability is a given, but it must be easy to manage. Ideally I'd like a mixed storage system, with the ability to arrange the tablespaces across the drives as I need. 50Tb is great, but I need the ability to put the high IOPS tables on an SSD, then spread the infrequently accessed tables onto large HDDs.
- qaq 10y ago
  Thanx for your input many of the frustrations you outline is the exact motivation why we are considering building this service.

by qaq 10y ago

audleman 10y ago

My 2 cents: you're promising a lot more for the same price which seems dubious. How are you going to beat the wholesaler? Even if you did I probably wouldn't use it. I don't want a 3rd party dependency on the most critical part of my infrastructure.

qaq 10y ago
The price would be comparable to AWS appropriate tear eg 6TB storage for a bit less (10-15%) then amazon's 6TB RDS option but with much better performance. I totally get your reluctance to rely on 3rd party, but the question is more for people who already do rely on 3rd party such as AWS or Azure.
- erkkie 10y ago
  How are you imagining solving latency issues? Many people want their DB to be close to their appservers. edit: and if it's an hosted service, I'm assuming decent networking options (ipsec et al)?
  - jbrantly 10y ago
    Exactly. I want my app server and my db server to be as close as possible. That's why services like Compose and ElephantSQL offer just that. So then it comes down to performance/price (value) between RDS and those.
    - qaq 10y ago
      Latency will be higher. We are considering if we do go forward: a) Partnerships with smaller providers where there is an option to colocate equipment b) Colocating as close to as possible to targeted providers. The main thing we are trying to figure out - if there is a need for service that has significantly higher tears then what Azure, AWS offers.
      - erkkie 10y ago
        I would imagine people who need either more AWS can supply (or cheaper) but cannot pay for it, and also haven't figured out how to run it themselves, to be a very limited set. Happy to be proven wrong though and curious about what you will find out :) Is there a way to keep in loop?
        qaq 10y ago
        The thing that is impractical to do on premise is "transparent scaling" say your load increases and you need a way bigger box that's the kind of problem the service can solve (take slave offline remount storage on a bigger box catchup on replication switch to slave repeat for former master). We are at the early stage just investigating if we should move forward so @andre1sk on twitter would prob the only place :)
- askldfhjkasfhd 10y ago
  > I totally get your reluctance to rely on 3rd party, but the question is more for people who already do rely on 3rd party such as AWS or Azure. Just a little input: Amazon and Microsoft are well known companies. I (and my superiors) think they can support us. Your company that I haven't heard of is not. It may be dumb sounding, but I won't get in trouble if I used AWS and something went wrong. How could I have known? With an unknown company, if something goes wrong, it's on me because I selected that vendor. Stupid perhaps, but important to understand.

sandGorgon 10y ago

Dont go for IOPS , but price. Make sure that there is replication and fail over... people at this stage just want to make sure that their data isn't lost. Use cheap hardware like ovh - you can beat AWS on price. Plus, googling for "hosted postgresql" is still something that can be competed upon.

Rezo 10y ago

When it comes to data, trust is key. Think about it this way: OCZ has on paper SSDs that are simultaneously both faster and cheaper than, say, Intel. But I wouldn't put a OCZ drive into the lowest budged ricer gaming PC I could imagine (let's just say that have a bit of a reputation, to put it lightly), and I should be rightfully fired if I suggested putting one in a server. Yes, your service might be massively faster, but... at 10-15% cheaper? No way! Not until you've been running for years with a great reputation. Now, if you enter the managed database space and pull a Digital Ocean ($5-$40 pricing vs comparable EC2 at $80-$400 AND better raw performance on top), then you can essentially create a new market niche. That's my suggestion to focus on, because businesses who operate 50TB databases aren't looking to save a few dollars. But people who use DO, need a database to go with it that is both faster and cheaper than AWS. Honestly, performance ranks pretty low on the things I've found people look for when choosing a managed database service. You can serve a million users per day and average a whopping 12 IOPS, which might just about push a Raspberry Pi with sqlite slightly. Got more than a million users? Congrats, you now officially qualify to throw money at problems, the kind of problems RDS and Amazon loves to solve by injecting money.

qaq 10y ago
You do not have an option to host anything larger then 6TB on RDS. I guess what we are trying to figure out is if there is a need for service for people who have needs beyond those RDS is addressing.
- yeukhon 10y ago
  Not only disk space, you are limited to just two nodes (one primary and one standby). Of course you can create read replica, but that if you are write intensive, you can end up consuming all of your pools.
  - merb 10y ago
    actually you would shard than, which of course is possible with rds aswell. since you mostly shard at the application level. there are some users that use extensions but I guess calling the support of aws will get these extension in your rds instances.

deleted 10y ago

[deleted]

adwf 10y ago

My priorities are: Reliability > Size ~= Price > Performance Reliability of a database is always no.1, without it, nothing else matters. So the customer must have enough access to the machine to setup replication and failover themselves (eg. using something like repmgr). Or have damn good guarantees that you're doing it well for them. ie. multiple replicas, verifiable backups, offsite backups, etc. Secondly is size. This is a major sticking point for me when looking at hosted postgres solutions - they're mostly for relatively small databases <1Tb or so. Closely in third is price. Even when you do find a service that provides a decent size like when RDS eventually went up to 6Tb (still not quite enough for me), the price they charge for it (and the ram) over buying dedicated iron is exorbitant. Given that 6-8Tb drives are mainstream now, it's a real head scratcher why they'll charge $750-1500/mth for a 6Tb drive that costs $250 outright. And then charge you for the IOPS on top of that... Even factoring in multiple redundant drives/replicas, SSD vs HDD, it's still very unfavourable. I can install 5 machines (at least) in a cluster for the price of 1 on RDS; giving me not just price savings, but my no.1 need - reliability. Finally performance. The number of high IOPS workloads out there is rather small. You're far more likely to have a high storage need with small IOPS, than high IOPS, smaller storage. Everyone overestimates the amount of traffic they'll get, and generally if you have an IOPS problem, it's better off fixed elsewhere in the app. Usually some bad code or ORM is thrashing the DB. Take a simple login DB as a thought experiment, just 10,000 IOPS is upto 864 million users logging in per day. Whereas the storage for that number of users, at a very generous 1Kb per user, is 864Gb. Size is way more important than IOPS. And if you've got that number of users, you've also got your own datacentre :) You might also run into the problem that the kind of organisations that need high storage + high iops are also the kind that wouldn't use the cloud for it in a million years (banks, high freq. traders, etc). In summary, I think the main thing that would attract me is high capacity storage for a decent price. Reliability is a given, but it must be easy to manage. Ideally I'd like a mixed storage system, with the ability to arrange the tablespaces across the drives as I need. 50Tb is great, but I need the ability to put the high IOPS tables on an SSD, then spread the infrequently accessed tables onto large HDDs.

qaq 10y ago
Thanx for your input many of the frustrations you outline is the exact motivation why we are considering building this service.