Live data from Hacker News

“Fashion Is Hard. PostgreSQL Is Easy” [video]

tech.zalando.com

121–130 of 140 posts

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#121
post #39

I had a job interview at Zalando a while ago, and apart from the huge bunch of bananas at the entrance to the developer's den, the one thing I remember most about was the fact that apparently they're using stored procedures for basically any database transaction. Which is probably a more unorthodox use of databases these days, at least for Postgres (I've heard it was more common for SQL Server and I once had the ques…

I use the holy hell out of stored procs and UDFs, and they have saved my bacon plenty of times.

Once you get past building todo lists, you'll end up with complicated transactions that do many different data mutations, usually along with some simple logic. You can either maintain your virtue and pay the latency price for each of those, or just code a proc that implements the whole thing. It might offend your software dogma, but it'll get shit done so you can get home to the wife in time for dinner. These days, that is the only deadline I care about.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#122

PostgreSQL is great, but I've gone back to MySQL because of the ease of which I can setup replication (which I like to use when possible in addition to automated/periodic backups).

RDS makes it trivial to have high availability if you can't afford a DBA worth their salt. You don't need 10x replication to beat the uptime of your shitty web app.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#123
post #15

Two years ago I switched from PHP and MySQL to Ruby and PostgreSQL. The only thing I'm missing is Sequel Pro. PG Admin is ok, does everything I need, but that interface is ugly and unintuitive. [1] http://www.sequelpro.com/

As of late, I've been doing php+pgsql and it's like easy+easy. My latest app was an absolute pleasure to code, and I haven't said that in a a long time.

I agree that pgAdmin leaves a lot to be desired. It needs something on par with SSMS.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#124
post #15

Two years ago I switched from PHP and MySQL to Ruby and PostgreSQL. The only thing I'm missing is Sequel Pro. PG Admin is ok, does everything I need, but that interface is ugly and unintuitive. [1] http://www.sequelpro.com/

Relevant Github Issue: https://github.com/sequelpro/sequelpro/issues/362

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#126

PostgreSQL is great, but I've gone back to MySQL because of the ease of which I can setup replication (which I like to use when possible in addition to automated/periodic backups).

RDS makes it trivial to have high availability if you can't afford a DBA worth their salt. You don't need 10x replication to beat the uptime of your shitty web app.

I thought so too, until I decided to use RDS for storing zabbix.

It looks great on paper, but unless you're doing development I would discourage its use. That said your original point about the replication is true, but there are shortcomings that come together with it.

Some things that you will learn if you use RDS:

- if you decide to increase volume size, change type to SSD or use provisioned IOPS, you might have database down for an hour or more. Regardless whether you use single instance or HA.

- want to upgrade 9.3.x to 9.4.x? Tough luck you have stop dump the data and provision a new instance. You can't use postgres' inplace upgrade method

- you have limited control regarding tuning, many settings require rebooting the whole thing, when normally you would just restart the process (with HA there's still several seconds of interruption)

- you can only use extensions that they provide, there's almost no extension to monitor performance

- you can't login to use shell to monitor the process (obviously, but it's a still shortcoming)

- can't replicate data across regions or outside of RDS (it could resolve some of the issues above)

- it can fail, we had two times a failure caused by AWS, it happened during backup period. Normally AWS does backup on the secondary database, but we learned that in those instances it got confused and was attempting to do it on primary, rebooted it and for about 15 min the database was unavailable.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#127
post #82

I love PostgreSQL. But for a personal project I went with MongoDB, because my data set was a perfect match for mongo's design. Now I love mongo too, I'm amazed with how easy it has been to maintain 100% uptime on comodity hardware (one server is literally in a room in my apartment) through all the random server downtimes, upgrades, migrations, etc. And now I have more ideas for some personal projects, and they would…

If mongo impresses you, you should check out rethinkdb: https://github.com/rethinkdb/rethinkdb

no official java driver :-/

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#128

I love PostgreSQL. But for a personal project I went with MongoDB, because my data set was a perfect match for mongo's design. Now I love mongo too, I'm amazed with how easy it has been to maintain 100% uptime on comodity hardware (one server is literally in a room in my apartment) through all the random server downtimes, upgrades, migrations, etc. And now I have more ideas for some personal projects, and they would…

If it's running on a desktop in your apartment, you don't need replica sets.

Why not?

It is a desktop (as-in, it has normal desktop components, although used headless like a server), but it's got plenty of RAM, good CPU, RAID1 on WD Re hard drives, 100mbit connection and hooked up to a UPS.

In the last year it has been more stable than some of the cheaper hosting I was using.

Besides, it's not running the whole replica set, just one member (out of 3).

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#129

I love PostgreSQL. But for a personal project I went with MongoDB, because my data set was a perfect match for mongo's design. Now I love mongo too, I'm amazed with how easy it has been to maintain 100% uptime on comodity hardware (one server is literally in a room in my apartment) through all the random server downtimes, upgrades, migrations, etc. And now I have more ideas for some personal projects, and they would…

I'm genuinely interested in which dataset/use case is serviced better by MongoDB than PostgreSQL

I didn't mean that it was serviced better by MongoDB rather than PostgreSQL.

I meant that it was a valid/recommended use case for MongoDB since I didn't really have any relational data (every document inserted was pretty much standalone).

I've mentioned it because I've seen plenty of posts around HN where "mongo sucks" because they tried to fit a round shape through a square.

The extra goodies from MongoDB helped too.

Like automatic failover, I can literally go and unplug a node and everything will still be fine.

Having tail -f functionality in the db was also pretty handy (for my project).

The sysadmin in me was happy too, it's not everyday you see software that allows you to upgrade between major versions / storage engines without downtime (when using replica sets, not standalone, of course).

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#130

I love PostgreSQL. But for a personal project I went with MongoDB, because my data set was a perfect match for mongo's design. Now I love mongo too, I'm amazed with how easy it has been to maintain 100% uptime on comodity hardware (one server is literally in a room in my apartment) through all the random server downtimes, upgrades, migrations, etc. And now I have more ideas for some personal projects, and they would…

do take a look if you can leverage jsonb datastructure of postgres - you get 80% of the power of mongo and all the advantages of postgres. https://www.compose.io/articles/is-postgresql-your-next-json...

Maybe I wasn't clear, I love everything about PostgreSQL.

But I would love it even more if it were easier to distribute (see replica sets in mongodb, with auto-failover and other goodies).

Post reply on HN