Live data from Hacker News

Just use Postgres

mccue.dev

191–200 of 238 posts

Re: Just use Postgres

#191

Almost all statements about MongoDB are wrong. > You know exactly what your app needs to do, up-front No one does. Mongodb still perfectly fits. > You know exactly what your access patterns will be, up-front This one also no one knows when they start. We successfully scaled MongoDB from a few users a day to millions of queries an hour. > You have a known need to scale to really large sizes of data This is exactly a g…

What percentage of projects hit a billion rows?

I guess one could write a lot of extra rows to try and get there.

Re: Just use Postgres

#192
post #38

When people say "Just use SQLite. It's almost as good as Postgres and you won't need anything more" I'm trying to understand why I shouldn't just use Postgres. It's not like it's hard to install or has any significant overhead. Please enlighten me.

Using a networked service makes your app a distributed system with all the associated hard things.

Re: Just use Postgres

#193
Every database has issues and quirks whether they be about how you design your application, how you need to scale, or how you need to maintain your database. You can play this game “just use XYZ and have no problems”, but it isn’t realistic. Production databases at scale require heavy dedicated infra to stay highly available and performant, and even out of the box solutions require you to understand what is going on and tune them else you run into “surprises” which are almost always that no one RTFM. Pretty much every mainstream database is capable of both highly available and highly consistent workloads at scale. The storage engine largely shouldn’t matter as much as the application tuning.

Re: Just use Postgres

#194

> If you see a college student or fresh grad using MongoDB stop them. They need help. They have been led astray. I like this sentence way more than I should.

Me too.

I'll give you one counter-argument, though: maybe it's hard to appreciate all of the problems a traditional SQL RDBMS solves until you try and solve them without an RDBMS... and crash and burn badly.

But, if they're actually building a real product with real funding money and they only know MongoDB... yeah, it's intervention time.

Re: Just use Postgres

#195
I do not get the reasoning around SQLite.

SQlite is easy to backup, especially if you are OK with write locking for long enough to copy a file. It now has a backup API too of you are not OK with that.

Lots of things do not scale enough to need more than one application server. A lot of the time, even though I mostly use Postgres, the DB and the application are on the same server, which gets rid of the difficulties of working over a network (more configuration, more security issues, more maintenance).

The main reasons I do not use SQLite are its far more limited data types and and its lack of support for things like ALTER COLUMN (other comments have covered these individually).

Re: Just use Postgres

#196
post #27
post #20

Earlier quoted context omitted.

more like PHP, which is funny because they always come in pair, prolly originate from the days of LAMP stack. js is more associated with Mongo, another bad db. Most modern js projects (or any modern project really, except PHP) use Postgres

20 years ago LAMP (Linux, Apache, MySQL, PHP) stack ~is~ was the most common combo of the web

Not sure about Apache, but Linux, MySQL and PHP is still the most common combo in terms of number of sites running it. Wordpress alone is enough to establish that.

Re: Just use Postgres

#197
post #186

Almost all statements about MongoDB are wrong. > You know exactly what your app needs to do, up-front No one does. Mongodb still perfectly fits. > You know exactly what your access patterns will be, up-front This one also no one knows when they start. We successfully scaled MongoDB from a few users a day to millions of queries an hour. > You have a known need to scale to really large sizes of data This is exactly a g…

>> When data size goes to a billion rows, Postgres is tough. MongoDB just works without issue. Our everyday problems... Tbh when you reach that size you will hopefully already have a dba department no matter what you use.

We don't have a single DBA or DevOps or SRE. MongoDB is really that simple.

Re: Just use Postgres

#198

Almost all statements about MongoDB are wrong. > You know exactly what your app needs to do, up-front No one does. Mongodb still perfectly fits. > You know exactly what your access patterns will be, up-front This one also no one knows when they start. We successfully scaled MongoDB from a few users a day to millions of queries an hour. > You have a known need to scale to really large sizes of data This is exactly a g…

> This is exactly a great point. When data size goes to a billion rows, Postgres is tough.

You’ve been led astray. You can handle a billion rows on a developer laptop, let alone a production grade instance.

Re: Just use Postgres

#199
post #170

Almost all statements about MongoDB are wrong. > You know exactly what your app needs to do, up-front No one does. Mongodb still perfectly fits. > You know exactly what your access patterns will be, up-front This one also no one knows when they start. We successfully scaled MongoDB from a few users a day to millions of queries an hour. > You have a known need to scale to really large sizes of data This is exactly a g…

> This is exactly a great point. When data size goes to a billion rows, Postgres is tough. MongoDB just works without issue. Personally, I've not seen any application that seriously needs a billion rows in a single table. (except at truly massive scale, but then you're not using Mongo) The real solution is implementing archiving to a file store like S3 and/or ship it off to a data warehouse. You don't need billions o…

May be we are the odd one here but we need that data at millisecond latency (no those are not logs, we use ClickHouse for that)

Just wanted to put here that it's possible to scale Mongo to this level.

Re: Just use Postgres

#200
post #173

Earlier quoted context omitted.

60x60x60 is 60 hours, not 1 hour. 1 hour is 3600 seconds. therefore 1 million queries per hour equal ~280 queries per second.

Oof, you're right. Still within the performance profile of a raspberry pi though, even if it's no longer off by an order of magnitude So I think my point still stand: that number is as low as you can get for any rdbms.

TBH we are at around 15M queries per hour. I am sure our customers don't want us to run on RPi. Btw, it's not only query but billion+ rows which are also there.
Post reply on HN