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

61–70 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#61

Post by bpye »

bunderbunder wrote: post #33
toomuchtodo wrote: post #8

Earlier quoted context omitted.

MongoDB by default is (was? It’s been a while since I’ve used it) schemaless, which means all of your data validation must take place in your app instead of the database. Your data integrity is then only as good as your weakest validation. Edit: scheme/schema autocorrect typos corrected. Thanks!

I've always preferred the terms "schema on write" and "schema on read" to schemaful/schemaless. At some point, you are always going to have to get the data into some sort of consistent model, so that you can operate on it in a predictable and sane way. So there's no question of there being a schema, even if it's only implicit. The question is, do you apply the schema once, when you write to the data store, so that th…

I'm tired and haven't often dealt with database systems. I'm struggling to see significant benefits for schema on read style systems - maybe progressive migration? I'm not convinced...

Re: Red Hat Satellite to standardize on PostgreSQL backend

#62

Post by baroffoos »

Bucephalus355 wrote: post #44
int_19h wrote: post #37

Earlier quoted context omitted.

On the contrary, RDBMS provides far more opportunity for validation, because it has all the data at its disposal, which can be queried as needed without the expense of crossing the boundary.

What is the purpose of validation would you say with modern computers? At one time, specifying the exact number of chars was good for squeezing out as much storage as possible, but less so today.

Its still absolutely critical for almost everything. Some use cases:

* My code depends on this value always existing so make this not null * My code is doing math on this value so make sure it is always a number * This record belongs to other record, make sure other record can not be deleted while this one still exists

Modern computers change next to nothing with the need to validate data. The worlds fastest computer wont tell you how to add a number that doesn't exist.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#63

Post by sonnyblarney »

jacques_chester wrote: post #35
sonnyblarney wrote: post #21

Earlier quoted context omitted.

RDBMS only provides a limited degree of 'validation'. It still must exist fairly comprehensively in the app.

Databases are, as their name suggests, closest to the data. Applications generally can't recreate ACID properties and specifically, they shouldn't be trying to.

"Applications generally can't recreate ACID properties" - why would they?

ACID and 'data validation' are generally separate issues.

Data generally has to be validated as it enters the business logic, before it gets stored in a DB. While a DB may in some cases ensure that data adheres to a schema, this usually does not fulfill all of the validation requirements.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#64

Post by d4l3k »

toomuchtodo wrote: post #18
chisleu wrote: post #17

Earlier quoted context omitted.

Right, but most people using it use model or data repository patterns to ensure correctness. It does offer nearly infinite flexibility provided you use it correctly. You can add fields without any sort of DB work, you just start adding fields to rows as needed and let it catch up organically. There are use cases where mongo makes a lot of sense. It's very popular in the node.js / RAD world for sure. I certainly have…

Unfortunately, I’d argue PostgreSQL gets you all the same benefits with JSON storage (fairly equivalent to Mongo docs), while also giving you all the goodness of a relational, transactional, schema enforcing RDBMS. PGSQL became Mongo faster than Mongo could become PGSQL.

Pretty much all of the things you'd want in a relational database are now present in Mongodb too.

The real benefit of MongoDB at this point is the ability to easily scale beyond a single machine with shards and high availability using replica sets.

Postgres will get you pretty far, but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution. At that point all the schema update and backups become a nightmare.

Schemas: https://docs.mongodb.com/manual/core/schema-validation/

Transactions: https://docs.mongodb.com/manual/core/transactions/

SQL: https://docs.mongodb.com/bi-connector/master/

Re: Red Hat Satellite to standardize on PostgreSQL backend

#65

Post by bpye »

leetrout wrote: post #53
bane wrote: post #29

Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.

In 2019. A LOT of people want MySQL over Postgres because of ignorance about how far Postgres has came and they don't know/care. I try to explain why I like transactional DDL and the guardrails that come with Postgres. With MySQL you end up having to use Percona to get a really robust DB setup with proper tooling that compares to Postgres in my experience. Both, of course, have plenty of known and unknown knobs you c…

And I'm sure one day some new DB will pop up, and for most workloads it'll be better. People will still use PostgreSQL because it was the right choice in 2019. So the cycle will repeat...

Re: Red Hat Satellite to standardize on PostgreSQL backend

#66

Post by geggam »

nodesocket wrote: post #15
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?

This is a dead horse that's been beaten to death over and over again here on HN. MongoDB is garbage. MongoDB doesn't scale. MongoDB is $h!t says HN users. It just feels like an echo chamber. Are you running the latest version of MongoDB in a replica set with journaling enabled and write concern set to one? MongoDB has worked great for my uses, up to moderate write/read scale. Sure, if you are running "big data" or en…

why would you require the latest version of a database to not have corrupt data ?

I can install 10 yr old database postgres / mysql software and not get corrupt data

Re: Red Hat Satellite to standardize on PostgreSQL backend

#67

Post by SteveNuts »

baroffoos wrote: post #54
toomuchtodo wrote: post #5

Earlier quoted context omitted.

I’ll allow it. Years later, I’m still miffed at Graylog (centralized logging engine) for having required MongoDB for a small bit of auth and meta storage that could’ve easily been done in MySQL or PostgreSQL (RDS even), forcing the need for that much more ops work for a small Mongo cluster for HA. Everyone deprecating the use of Mongo is a welcoming turn of events. I shall recall these dark days to the next generatio…

Setting up graylog was one of the worst mistakes I made. It took forever to get all the required software installed and configured and then it was taking up all the ram on the server doing fuck all.

That was just Java doing Java things. Business as usual.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#68

Post by leetrout »

bpye wrote: post #65
leetrout wrote: post #53

Earlier quoted context omitted.

In 2019. A LOT of people want MySQL over Postgres because of ignorance about how far Postgres has came and they don't know/care. I try to explain why I like transactional DDL and the guardrails that come with Postgres. With MySQL you end up having to use Percona to get a really robust DB setup with proper tooling that compares to Postgres in my experience. Both, of course, have plenty of known and unknown knobs you c…

And I'm sure one day some new DB will pop up, and for most workloads it'll be better. People will still use PostgreSQL because it was the right choice in 2019. So the cycle will repeat...

Without a doubt. Lots of movement around specializations (ML/AI datasets) and decentralization...

When the tasks we're solving are fundamentally different than I expect the tools to support those tasks will be fundamentally different, too.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#69

Post by duxup »

bane wrote: post #31
toomuchtodo wrote: post #5

Earlier quoted context omitted.

I’ll allow it. Years later, I’m still miffed at Graylog (centralized logging engine) for having required MongoDB for a small bit of auth and meta storage that could’ve easily been done in MySQL or PostgreSQL (RDS even), forcing the need for that much more ops work for a small Mongo cluster for HA. Everyone deprecating the use of Mongo is a welcoming turn of events. I shall recall these dark days to the next generatio…

I once worked at a place that, at some point in the past, had developed some kind of semantic graph database that never gained market traction. The author of it had ended up as CTO and kept seeking out uses for his work and ended up finding all kinds of odd places for it to live, including as the auth database in a large scale document analytics system and running part of the payroll. We were constantly running into…

I worked for a company that was old but had a fancy new product. It was just about to be released when....

A competitor bought us for stupid money. They fired most folks (not my small department) had their CTO decide between our fancy new product, and the product he created. There was no question, our product was amazing, his Frankenstein was two pieces of equipment cabled together in three items the footprint ... and still did less, and was quite a ways away from being "ready".

If there was a silver lining, the Frankenstein product doomed that company and we got bought by the far more competent competitor they had.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#70

Post by unethical_ban »

bane wrote: post #29

Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.

Compelling reason #1: We don't need hot-warm HA and don't want to fight for a database with IT every time we write a homebrew app.

We use SQLite.

Post reply on HN