I have to say, I'm extremely disappointed by the pricing. It doesn't seem any cheaper than AWS's managed SQL offering (through Lightsail), nor cheaper than Cloud SQL.
I'm trying to run a side project at a low rate, which is usually why I go to DigitalOcean - it's much cheaper, than, say, spinning up a bunch of Heroku dynos. In fact, I just moved a project from Heroku to DO to go from a $14/mo hosting bill to $5/mo on the cheapest VPS.
My one problem has been Postgres - I don't want to self-manage a database. However, Cloud SQL is ~$9/mo at the cheapest, and RDS/Lightsail are both $15/mo at the cheapest. I'd really been hoping that DO would provide a lower-cost alternative.
I'm really sad that the pricing structure doesn't bring managed databases down to hobby-tier. I don't even want a free offering; I'm happy to pay gig of space for $5/mo to run in perpetuity, with restrictions on backup retention or something.
Right now, if I'm an actual startup or even bootstrapped company with money, I see _zero_ reason to use DO's offering over your more-established competitors, and as a hobbyist user, I can't justify spending money on it for a no-income side project.
At the point you care about backups and standby nodes, you're already sort of outside the cheapo hobby tier.
As for getting the $5/month option: Digitalocean Droplets have a 1-click Dokku install, and you can use https://github.com/dokku/dokku-postgres to instantly pop up a postgres instance.
That's kind of fair. I've been doing some thinking since posting this, and I've been sort of debating what a "reasonable $5/mo version" of this would be. The more I think about what managed database services usually entail, the more I concede that my original request probably isn't really a viable product (unless it was a "free tier"-style loss leader). Like, disk space and bandwidth aren't really the primary cost involved.
I think what I really want is managed backups that live outside of my box, and the ability quickly restore from one if my database crashes or becomes unusable. I think automated failover to another node may not be a reasonable ask for such a cheap product.
Of course, at that point: I could spin up a 1GB DigitalOcean volume for $0.10/mo, and set up scripts to run `pg_dump` every couple hours, clean the volume of older backups to free up space, and ideally a script to reset the database to a given volume. _That's all stuff I don't want to do_, but maybe someone's built a reusable set of scripts for it or something - that Dokku container is promising as a starting point, though I'm a little annoyed it only works with S3(-compatible).
I suppose I could also use DO's Spaces, which is S3-compatible, though also has an annoying minimum (I do not need the 250 gigs you get for $5/mo) https://www.digitalocean.com/products/spaces/
Was about to chime in the same... dokku is great for the hobbiest/cheapish tiers... I wouldn't go below a $10/mo instance, but you can throw a surprising amount of work at it at the lower end.
Why would you be afraid to self-manage a database for a side project? It isn't very hard to install and run, especially if you don't need to tune the system for massive load.
When configuring a number of standby nodes > 1 what replication topology is used? Are {all,none,some} replicas synchronous?
Is the postgres super user available?
What is the list of supported extensions?
Can WAL (physical/streaming) replication be configured to a non-managed postgresql instance? I'm assuming logical replication slots should be supported.
Is there in-built streaming backups/point in time restore?
Any details you can share on how failover and general cluster management is performed?
Are version upgrades supported? Assuming that would use pg_upgrade but is there an option for downtime-less upgrades using logical replication?
I'll bet it's async replication with streaming. Anything else costs too much in complexity and performance. Of course the cost of such a setup is a small window where data loss is possible -- but if you're ok with this service you're already ok with data loss because the daily backups lose any add+delete operations you do in a day (unless you have triggers that copy the deleted data in a shadow table)
Some of these are from our support playbook and I'm working on getting a few others.
> When configuring a number of standby nodes > 1 what replication topology is used? Are {all,none,some} replicas synchronous?
Trying to get an answer of this one.
> Is the postgres super user available?
At this time only our administrative users are superusers for the database. All other administrative tasks should be possible from the default "doadmin" user provided when setting up your database cluster.
You can see a list of current users in the database (including ours) with this command from the Postgres CLI: \du
If some administrative task isn't possible with the "doadmin" user just let us know and we can report that to our engineering team for review and potential future change. We can't promise anything immediately, but we can definitely look into changes long-term!
> Can WAL (physical/streaming) replication be configured to a non-managed postgresql instance? I'm assuming logical replication slots should be supported.
No, not available.
> Is there in-built streaming backups/point in time restore?
Only daily backups are available with our managed database service at this time. We maintain 7 days worth of backups for each database cluster. Backups can be viewed and restored from the Cloud Control Panel by clicking on your cluster and going to the "Backups" sub-tab. This will restore your entire database cluster to that point in time.
While the backup frequency can not be adjusted to more often/weekly/monthly, you can take point-in-time backups by creating a "fork" of your database cluster. The fork can be placed at a specific point-in-time (reference your logs to find out when the transaction happened modifying the data you want to get back), or "now".
> Any details you can share on how failover and general cluster management is performed?
Nodes are monitored and failover happens automatically with minimal downtime if a node becomes unavailable. Some more info [0].
> Are version upgrades supported? Assuming that would use pg_upgrade but is there an option for downtime-less upgrades using logical replication?
I _think_ all updates may require powering off but will try and confirm.
I recommend adding these points to the website once you know them.
Especially not knowing whether it's synchronous or non-synchornous replication makes it impossible to design systems on it, as that decides whether you can lose some (likely small) amount of data on a failover, or whether the system guarantees nothing is lost.
I also don't understand another key thing:
On the Pricing page you write "Standby nodes with automated failovers". At the same time, the pricing table offers 0, 1 or 2 standby nodes. So what happens if I buy the offer with the 0 standby nodes, and a failure occurs? Is my data gone? Does DO replace the failed node, and how when there are no standbys?
Kamal from DigitalOcean here. With only a primary node and no standby nodes, a failure will cause a new replacement node to be created with its data being a combination of the latest backup and the write-ahead log. This will get you the most recent data possible. Check out this page for more info on auto failover and how it works with the different configurations: https://www.digitalocean.com/docs/databases/resources/high-a...
How is the WAL stored? If there is a problem with the storage, networking, or DC, you will not be able to get the WAL in order to bring up the DB in a new region. Also, the process of replaying WAL since last backup can take a very long time for a high traffic DB, during which time it is going to be completely unavailable.
The WAL and all backups are stored offsite and are completely handled on our end.
Re: availability, that’s right if you only have a primary node and no standby ones. Like manigandham said, there won’t be any downtime if you have a standby node.
Thanks. Will you offer a synchronous version in the future?
Since asynchronous means that you can lose previously acknowledged writes when the primary node crashes, which forbids many use cases (for example, most things involving money).
And Postgres already offers synchronous replication modes.
This is super helpful. Agreed with other comments about making this available more readily on the DO Managed DB pages.
Having looked through the set of extensions, wal2json (https://github.com/eulerto/wal2json). That makes sense since there's no way at the moment to get access to replication.
However, the use case for wal2json in addition to the access to replication is that it's the best way that I know of to get reliable change notifications from the database. I personally use this to pipe the JSON blobs into message queues to be consumed by applications.
As a short aside, I don't use PostgreSQL's NOTIFY/LISTEN because, as I understand it, you will not receive messages if there are no connections to the DB -- this is a show stopper for me.
AWS RDS allows this and Google's PostgreSQL does not. I've personally abandoned Google's version first partly because it seems to have stalled in terms of upgrades, and AWS for being way too expensive for what you get. Although it doesn't work for me at the moment, I'm hoping the DO option will work for me in this regard in the not so distant future.
Are the SSDs on these located in the servers that the DBs run on, or do they live on a separate SAN?
I ask, as at a previous job, we used to run our Postgres DBs on raw Droplets, and we'd get awesome performance on disk bandwidth (which we really needed), so much so that if we'd have moved to AWS we'd have had to pay very significant $$$ for provisioned IOPS to get the same bandwidth.
It'd be awesome if that same performance/price ratio was available with these new managed DBs.
Do you have any plans for supporting logical decoding plug-ins? Would love if it was possible to enable change data capture out of Postgres on DO with Debezium (which currently supports wal2json and its own DecoderBufs logical decoding plug-in). Disclaimer: I'm the lead of Debezium.
What is the reason behind the limit of 22 connections for the small 1GB instance? I've noticed that PgBouncer can be configured automatically, but still standalone PG should be able to support more than that.
Each open connection is a fork that takes up ~10MB. There is actually a 25 connection limit (3 are reserved for maintenance) so that's ~250MB just on connections.
Is there any plans to open data-centers in the South of the US? (Texas specifically), we want to consider DO but the high latency from the current ones is not an option.
Hey Eddie! If you guys could please take a serious look at split-horizon DNS, that'd be awesome! I can't wait for the MySQL launch, we'll be first in line
