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

241–250 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#241

Post by mr_overalls »

kevinmgranger wrote: post #98
int_19h wrote: post #43

Earlier quoted context omitted.

Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). If you need ACID, then start with SQLite. If you need scalability as well, then PostgreSQL. Most other features aren't worth the hassle of configuration compared to a single file on disk and a library to link to. (But I suspect that most NoSQL apps these days would do just fine w…

For most languages and frameworks, using Postgres as opposed to sqlite is barely a higher cost if you’ve got the ops skills. I’ve yet to see an app that straddled this local/web-scale line where SQLite was a better choice or Postgres wasn’t the obvious choice. There isn’t some massive cost to using Postgres instead, is there some desktop divide I’m missing here?

From: https://www.sqlite.org/whentouse.html

Appropriate Uses For SQLite:

SQLite is not directly comparable to client/server SQL database engines such as MySQL, Oracle, PostgreSQL, or SQL Server since SQLite is trying to solve a different problem.

Client/server SQL database engines strive to implement a shared repository of enterprise data. They emphasize scalability, concurrency, centralization, and control. SQLite strives to provide local data storage for individual applications and devices. SQLite emphasizes economy, efficiency, reliability, independence, and simplicity.

SQLite does not compete with client/server databases. SQLite competes with fopen().

Re: Red Hat Satellite to standardize on PostgreSQL backend

#242

Post by lowercased »

chrisseaton wrote: post #89
ousta wrote: post #85

Earlier quoted context omitted.

i struggle to see why in-memory data structure is the way to start can you please explain. do you create json for all your users?

> i struggle to see why in-memory data structure is the way to start can you please explain. It’s much simpler. The idea is to start simple and avoid complexity. Do you need the extra complexity of a PostgreSQL instance or can you get away with doing it in-memory? If so you can save yourself a lot of complexity.

> If so you can save yourself a lot of complexity.

The complexity exists, you're just shifting it around some. The "complexity" of setting up a populate db server is non-zero, but generally a known-entity. The complexity of managing your own stuff 'in-memory', with all the attendant issues about concurrency/corruption/performance/etc - would almost always end up being far more custom to your particular project.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#243

Post by dralley »

zaphirplane wrote: post #196
jayd16 wrote: post #76

Earlier quoted context omitted.

Not being worth the effort isn't much better.

You are assuming it’s the technology I’m assuming it’s the licensing change.

As someone on the team, it's not the licensing change. The post is correct when it says we've been slowly working on this since 2016. The license change certainly validates the decision, but it was made for purely technical reasons.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#244

Post by amyjess »

dmoreno wrote: post #236

This sentence, when talking about support for old enterprise versions, is a bit suspicious: > Satellite will not use newer versions of MongoDB that are licensed under SSPL. So my read is that there is not only an intention of database consolidation, but also a desire of avoiding the SSPL.

Nothing "suspicious" about it.

Red Hat also explicitly evicted Mongo from RHEL 8 because of the SSPL [0], and they have a longstanding policy of only shipping OSS.

It's no secret, and they've been very upfront about not shipping anything SSPL.

[0] Previous HN discussion: https://news.ycombinator.com/item?id=18919543

Re: Red Hat Satellite to standardize on PostgreSQL backend

#245

Post by pjc50 »

arendtio wrote: post #227
skunkworker wrote: post #112

Earlier quoted context omitted.

Yup this. People don't realize just how performant SQLite can be. If you are running just 1 server and won't probably need more than SQLite is more than enough. 2 application servers and up is where PostgreSQL can come into play. https://www.sqlite.org/whentouse.html After reading the SQLite when-to-use document I transitioned some smaller marketing sites over from Postgres because it was overkill for the specific si…

The biggest problem with SQLite is that it seems to be easy to use it wrong. If you are using SQLite as it is supposed to be used, it has much better performance than its reputation suggests.

In what way?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#246

Post by eftpotrm »

BossingAround wrote: post #157

A silly, genuine question: when I'm writing a NodeJS app, and I need to store a JSON in a DB that looks like this: { "a" : "b", "c" : { "ca":"cb", "cd":"ce" }, "d": { ... } } How do I store it? To me, NoSQL seemed like the choice in the past. This is not difficult in relational DBs, but it requires rather long SQL commands, and SQL table design. It seems to me that "MongoDB.insert(obj)" seems like the way to go, as i…

Commenting from a SQL Server perspective as it's what I know best - there's a native JSON data type, so you're absolutely able to store JSON in columns and interact with it as such.

If you don't mind getting a bit more sophisticated..... Certainly with XML (the JSON tools weren't as mature as the XML ones, though they're hopefully improving) it isn't tricky to sling a document at the database and have it create a whole tree of very standard RDBMS-style table records. Nor is it that tricky to write code which, when given the ID of a record, returned it and its children as a document tree.

Whether it's the right approach for you is another matter, but it's very doable.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#247

Post by vp8989 »

foobiekr wrote: post #14
Bucephalus355 wrote: post #6

Earlier quoted context omitted.

Wow was MongoDB really that bad?

A way to think about that question is to ask whether typelessness in general is bad because a lot of the schemaless databases come from that side of the divide. I’d personally answer yes, but that’s because I believe that typed, schema-generates structures should be pushed all the way from the database to the typescript code on the front end. Changes become something you can deal with with high confidence and things…

"I suspect it’s a personality thing."

I do too. And also probably a lack of experience dealing with outages and remediation of mistakes.

If it's always someone else's problem to clean up your mistakes then you can't appropriately appreciate how valuable it is that a machine can help you make less of them.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#248

Post by tim333 »

int_19h wrote: post #119
jeffdavis wrote: post #107

Earlier quoted context omitted.

"Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format)." That sounds like a bad idea in many cases. Prone to many kinds of problems, like accidentally corrupting the stored state beyond recognition from a tiny application bug.

How exactly would you corrupt it? For all the stuff that's in-memory, it's as safe as your language is. If you're writing it to disk all at once, it's easy to implement this atomically with rename - this guarantees that you have either the old file or the new file, but not some weird in-between state. And if you mean corrupting by the app going amok and asking to corrupt data because of logic errors in the app itself…

I had a python script that was roughly:

read file, unpickle, do stuff in memory, pickle, write.

A bug in "do stuff in memory" could easily muck things up and I didn't get round to renaming the file for every edit. Yeah you could do some auto rename thing but it might be simpler to just use sqlite.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#249

Post by joshklein »

mr_overalls wrote: post #241
kevinmgranger wrote: post #98

Earlier quoted context omitted.

For most languages and frameworks, using Postgres as opposed to sqlite is barely a higher cost if you’ve got the ops skills. I’ve yet to see an app that straddled this local/web-scale line where SQLite was a better choice or Postgres wasn’t the obvious choice. There isn’t some massive cost to using Postgres instead, is there some desktop divide I’m missing here?

From: https://www.sqlite.org/whentouse.html Appropriate Uses For SQLite: SQLite is not directly comparable to client/server SQL database engines such as MySQL, Oracle, PostgreSQL, or SQL Server since SQLite is trying to solve a different problem. Client/server SQL database engines strive to implement a shared repository of enterprise data. They emphasize scalability, concurrency, centralization, and control. SQLite s…

I like the way I recall someone (Richard Hipp?) putting it: SQLite is a file format.

SQLite is an efficient file format for relational data with excellent tooling.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#250

Post by duxup »

qbaqbaqba wrote: post #235
duxup wrote: post #69

Earlier quoted context omitted.

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 ... an…

Happy ending.

It's surprising how that works. I've been through numerous mergers, acquisitions, been in the company acquiring a company.

Lots of hair pulling and I can say that it was really hard to predict the outcome for any individual positive or negative in every case until long afterward.

Post reply on HN