Continuously blown away with the quality and usefulness of Postgres. It is truly lightyears ahead of MySQL and I keep wondering wth took me so long to switch. Kudos.
Meanwhile, it seems like AWS RDS have more development on MySQL and their own MySQL compatible engine (aurora?). At least they have Postgres RDS though. Google Cloud does not offer any hosted Postgres solutions. Cloud SQL is all MySQL.
I love Postgres but I really don't like maintaining rdbms installations.
What is my best bet running pg on google cloud with ha and minimun hassle?
Now if you need Postgres specific features... gets more tricky. Setting up FT is terribad.
I'd expect that if you run two Postgres servers, unaware of each other, at the same IP address you will rapidly get data corruption, but maybe I'm missing a step since you say this works fine for a lot of people.
If you would want to put multiple databases on one host, probably more efficient would be still to put all data in single instance. I could see this if it's a very small database, then this could work, but then wouldn't you be better off with using SQLite?
In additions when you add containers to the mix you turn a single problem into many, some examples:
- assuming you have multiple hosts, you need to figure out where you'll store persistent data (and you generally want a solution with high IOPS) - how you handle logging (where you store them?) - how the applications figure out where your database is (service discovery) - how you solve replication (and figure out which database is the master) - how you handle failover
Wouldn't you have similar problems with Postgres without the container?
Typically to make the database highly available you might set up a second one (or perhaps more) that replicates from the master. This can become problematic if the postgres containers will be moved around.
As I said, I don't know kubernetes, if you for example can have containers that have state (e.g. you destroy and recreate it somewhere else, and they are exactly same) and also keep the same IP then this is not an issue, but if when you move it around and each instance is technically a new postgres, then such setup might become problematic.
Regarding your question, the traditional way of running it is that you set up a host and run postgres on it. It doesn't move around so you need those solutions. Granted that for example if you implement service discovery for example if something happens to a host, you can set up another and quickly point everything to it.
Another option is intoGres: https://www.intogres.com.
> Add support for logical decoding of WAL data, to allow database changes to be streamed out in a customizable format.
Also 9.5 added new metadata to it [2]:
> Each WAL record now carries information about the modified relation and (s) in a standardized format. That makes it easier to write tools that need that information, like pg_rewind, prefetching the blocks to speed up recovery, etc.
Hopefully we will see the ecosystem pick up on those changes. Percona made a killing in helping replication take place in MySQL. I don't see why this would not happen with postgres.
I'm confident things will improve.
[1] http://www.postgresql.org/docs/9.4/static/release-9-4.html
[2] http://michael.otacoo.com/postgresql-2/postgres-9-5-feature-...
Maybe only tangentially related, but they also made enhancements to pg_receivexlog that make it acknowledge transactions over the wire.
It may not seem like a big deal, but with those changes I was pretty trivially able to patch a version of pg_receivexlog that replicates WALs to HDFS and flushes them (instead of the local FS), so that you can essentially treat HDFS nodes as synchronous standbys. Incredibly useful for setups where your only non-ephemeral storage is HDFS, and the 16MB chunk boundary imposed by archive_command is too course-grained.
I'd imagine similar things can be written for lots of other non-posix filesystems that support appending and flushing... Being able to replicate to something that's not just another plain old server is really useful (not to mention how much simpler it is than having to set up an entire other Postgres node just to synchronously ship logs.)
Don't get me wrong here, PostgreSQL is light years better but that's the big "why".
Postgres now has a variety of foreign data wrappers available and can serve that exact same function.
1TB (with only 100GB of RAM) will set you back $150k a year!
For comparison we pay our generic service provider about 20% of that to manage 2 redundant dedicated servers with 24/7 monitoring and support.
This is one reason I personally have a hard time moving away from MSSQL (despite the obscene licensing). Clustering, replication, and failover of MSSQL on Windows is really quite powerful. Though not necessarily cheap or easy to setup and troubleshoot, it is wonderful when it works.
However, they are super expensive. Considerably more than running yourself, and considerably more than CloudSQL or RDS on AWS.
Their plans are so small it seems that they're not really made for running anything big. Aiven's biggest plan is 3 nodes, each with 8 cores and up to 32GB RAM.
Elephant's most expensive plan is 1 node with 4 cores and 15GB RAM. Not sure if you just buy multiple of these. They have replication support, but I don't see anything about pricing, and they don't have automatic failover.
Mail me if you'd like to be in the beta - pjlegato@databaselabs.io.
While PostgreSQL replication may be a bit clunkier on the initial setup, it's a dream comparatively.
Temporal tables: https://wiki.postgresql.org/images/6/64/Fosdem20150130Postgr...