Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat Satellite to standardize on PostgreSQL backend

redhat.com

Post reply on HN
Print view View original

201–210 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#201

Post by raphaelj »

PurpleRamen wrote: post #166
sandGorgon wrote: post #158

Earlier quoted context omitted.

postgres has a jsonb datatype that works pretty much like mongodb. https://blog.codeship.com/unleash-the-power-of-storing-json-...

But will it perform as good as a dedicated nosql-db? Will the abilitys match? The querys? There usually is a tradeoff when something is forced into something alien. Is this the case here too?

IIRC, Postgres use a key-value store internally, so it does not really matters if you store records (i.e. tables) or objects (i.e. JSON documents).

There was an article on HN a couple of months ago that was comparing Mongo and PgSQL performance, and PgSQL ended up being as fast if not faster for most use cases.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#202

Post by anarazel »

raphaelj wrote: post #201
PurpleRamen wrote: post #166

Earlier quoted context omitted.

But will it perform as good as a dedicated nosql-db? Will the abilitys match? The querys? There usually is a tradeoff when something is forced into something alien. Is this the case here too?

IIRC, Postgres use a key-value store internally, so it does not really matters if you store records (i.e. tables) or objects (i.e. JSON documents). There was an article on HN a couple of months ago that was comparing Mongo and PgSQL performance, and PgSQL ended up being as fast if not faster for most use cases.

I don't see how you'd describe postgres validly as a key-value store at the storage level / internally. It's a pretty traditional row-store (without support for index oriented tables), i.e. all columns of a table are stored together. At the storage level there's no designation of what the key of a row is. Of course you can have primary keys, but that's a higher layer concern.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#203

Post by hartator »

Benjamin_Dobell wrote: post #79
hartator wrote: post #71

Not sure I understand the MongoDB hate here. Migrations and denomalization is not somthing you have to deal with in MongoDB.

You almost certainly still need to worry about migrations. MongoDB can store data in a schemaless fashion, however, chances are your application has a data model (schema). Sure, you can avoid migrations and just tack on more and more backwards compatibility for old data layouts. But performance suffers, and chances are that code quality and correctness suffer too.

You have to deal migrations maybe 1/20 the times than with SQL. Like no migrations for new tables, new db, and new columns. Column name changes can be handled on the application side or yes with a migration.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#205

Post by hartator »

world32 wrote: post #187
hartator wrote: post #71

Not sure I understand the MongoDB hate here. Migrations and denomalization is not somthing you have to deal with in MongoDB.

The migration comment has already been addressed. "Denormalization is not somthing you have to deal with in MongoDB." What do you mean exactly? If you have a piece of data, lets say an address, that exists in more than one place as is the mongodb way, you will absolutely have to deal with the fact that you need to now update that data multiple times. So denormalization is very mcuh some you have to deal with in Mongo…

Denormilization is not the thing because normalization of data in document db just results in what will heavy denormalized SQL. Like the address fields will be document inside the document. Instead of user_address_1_zipcode, you’ll get user: addresses: [ { zipcode: ... } ] }. It seems more elegant to me. But, yes you do have to update everywhere manually.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#207

Post by nailer »

raphaelj wrote: post #201
PurpleRamen wrote: post #166

Earlier quoted context omitted.

But will it perform as good as a dedicated nosql-db? Will the abilitys match? The querys? There usually is a tradeoff when something is forced into something alien. Is this the case here too?

IIRC, Postgres use a key-value store internally, so it does not really matters if you store records (i.e. tables) or objects (i.e. JSON documents). There was an article on HN a couple of months ago that was comparing Mongo and PgSQL performance, and PgSQL ended up being as fast if not faster for most use cases.

Can I make queries into nested keys of those objects?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#208

Post by bostonpete »

bubaflub wrote: post #4
alrs wrote: post #2

Is there a word for a case of "I told you so" that went on for so long that it curdled from frustration, to despair, to cynicism, to a realignment of your understanding of the human project as something barely capable of tying its own shoes and making it out to the mailbox and back?

Smug self-righteousness

Wish we had HN gold for comments like this.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#209

Post by detaro »

nailer wrote: post #207
raphaelj wrote: post #201

Earlier quoted context omitted.

IIRC, Postgres use a key-value store internally, so it does not really matters if you store records (i.e. tables) or objects (i.e. JSON documents). There was an article on HN a couple of months ago that was comparing Mongo and PgSQL performance, and PgSQL ended up being as fast if not faster for most use cases.

Can I make queries into nested keys of those objects?

yes

Re: Red Hat Satellite to standardize on PostgreSQL backend

#210

Post by linkmotif »

I’ve never enjoyed Mongo for a second, not conceptually, not practically.

But I don’t understand the people who act like Postgres is the end of everything. SQL never felt right for me either. It’s a fine language for business analysis, I guess, but is it actually pleasant for development? Do all of you who so enthusiastically post that it should be the first tool you reach for really never experience object-relational impedance? Do you really enjoy modeling like this?

Post reply on HN