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

181–190 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#181

Post by __david__ »

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.

From a certain perspective, adding backwards compatibility for old data layouts is a migration. A migration that gets run every the data is loaded instead of once during a classic db migration. This is inefficient in the long run.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#182

Post by fauigerzigerk »

skunkworker wrote: post #112
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…

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…

If only SQLite had a decimal type. I would be using it a lot more. I know all the workarounds but they are tedious and error prone.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#183

Post by staticassertion »

stephenr wrote: post #155
RhodesianHunter wrote: post #151

Earlier quoted context omitted.

That might make sense if they didn't also offer a plethora of their own built-in-house as well has managed oss relational DBS.

None of those OSS relational DBs offer Amazon lock-in the way DynamoDB does - it's more reliable income if someone uses it, but it also takes more convincing for people to use it. What enterprise would use it if Amazon themselves don't?.

This argument makes no sense at all. What does lock in have to do with Amazon dog fooding its services? They're... trying to lock themselves in? What?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#184

Post by aljarry »

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?

I can use SQLite for prototyping without db server.

It's a file or some in-memory buffer, I don't need docker or anything else to run some very simple unit/integration tests with the DB.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#185

Post by ngrilly »

int_19h wrote: post #43
bane wrote: post #29

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

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…

SQLite is really great, but as a datastore for a web app or a web service, it lacks a few important things to my eyes: - Cannot rename or drop column - Cannot create an index concurrently (without blocking writes) - No remote protocol (you have to use the CLI through SSH to run ad-hoc queries)

Re: Red Hat Satellite to standardize on PostgreSQL backend

#186

Post by stephenr »

staticassertion wrote: post #183
stephenr wrote: post #155

Earlier quoted context omitted.

None of those OSS relational DBs offer Amazon lock-in the way DynamoDB does - it's more reliable income if someone uses it, but it also takes more convincing for people to use it. What enterprise would use it if Amazon themselves don't?.

This argument makes no sense at all. What does lock in have to do with Amazon dog fooding its services? They're... trying to lock themselves in? What ?

Amazon owns Dynamo DB, and make it available via AWS. If customers use it for non-trivial applications, they have some degree of lock-in, because they can't just migrate to another (self-)hosted instance of e.g. Postgres, MySQL, Oracle, Mongo, what have you.

So Dynamo is an opportunity for Amazon to generate lock-in through their own proprietary software.

But big and likely even medium size businesses are less likely (compared to tiny companies that barely go above the free threshold) to use a new technology without any big well known users, or publicly documented use-cases etc.

One big way companies can provide some confidence to potential customers about their technology is by dogfooding: they use the thing they're trying to "sell" (regardless of whether it's a licence, a service, whatever).

Re: Red Hat Satellite to standardize on PostgreSQL backend

#187

Post by world32 »

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 Mongodb.

Just like in a relational database, denormalization has serious consequences and should only be used when the need for performance outweighs the risks of having much more complex code and hence potentially many more hard-to-debug errors.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#188

Post by bushin »

int_19h wrote: post #135
sonnyblarney wrote: post #101

Earlier quoted context omitted.

"data is data, it's either valid, or it's not. That's why the schema is about the data, not about the app." This is not true. The objective of the overall app/system (i.e. front/back/middle/DB/storage/services etc.) is to carry out some kind of business logic. A DB schema cannot fully validate stored data against the logic. Otherwise we wouldn't write backend code, we'd just write a bunch of schemas and be done with…

> The DB may only care that it's UTF and max 20 chars. But the system requires more validation than that. Are you familiar with SQL constraints, triggers, user-defined functions, stored procedures?..

lmao, “my schema is my app layer”.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#189

Post by purple_ducks »

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…

> A LOT of people want MySQL over Postgres because of ignorance

or you know, for multi master cluster pretty much out of the box. Gallera DB.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#190

Post by general8bitso »

manigandham wrote: post #162
pjmlp wrote: post #113

Earlier quoted context omitted.

Looking around the office and my phone, Java is anything but "legacy". As for alternative JVM languages, while they are cool and have brought many fresh ideas into the platform, they remain a very tiny portion of the Java developers' market. Java takes a very long time, because backwards compatibility and cooperation among giant companies takes years. C# has basically Microsoft deciding how the roadmap looks like and…

Runtimes are different from languages. The C# language has never been rebooted and is fully backwards compatible, and there's no better example of long-term support than Microsoft. You can still run apps from the MSDOS era, and even upgrade MSDOS through to Windows 10 if you have all the CDs today.

So, like DOS 3.3 to 5 to 6.2, and Windows 3 to 3.1, to 95 to 98 to 98SE, to ME, to XP, to 7, to 8 to 8.1, to 10?

I think I was using floppies until Win 98?

Post reply on HN