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

Goodbye MongoDB, Hello PostgreSQL (2015)

developer.olery.com

Post reply on HN
Print view View original

101–110 of 172 posts

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#101

Post by fhunt »

Jean-Philipe wrote: post #81
technosamay20 wrote: post #55

There were many questions asking about recent experience with MongoDB. I have some recent experience so wanted to share with everyone. My background: 2007-2010: Used MySQL to run a social network for 50M+ users. Would send 2B messages on peak days. All powered by Mysql. 2015-2020: Used Mongo to power a top 5k site. Zero downtime and dataloss in 5 years. Used Postgres for internal non user facing database So I have fa…

> With mongo, you just add a column and you are done. No, usually you are not done. Your data doesn't have the column. So either you write your code in a way that it can handle the column being optional or you write code to read each document and add the column manually. I've started out with mongodb on Fit Analytics originally, until we noticed at some point that our data was an inconsistent mess and we'd implement…

> our data was an inconsistent

Because you didn't put strict validation before data entered Mongo and I guess you didn't use a typed lang which makes such a validation like a no-brainer and quite natural.

SQL gives you type checking for free, Mongo does not. However, if you have a typed lang and have a proper validation in place you just have to define those at one place and not in the database and in your app (DRY).

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#103

Post by vorticalbox »

StreamBright wrote: post #20

These articles never get old. Hey we picked solution A and realized that it has some cons not only pros and now we are moving to solution B that only has pros. Few years later there is a new article, hey we are moving to solution A|C because...

here is one from Last year where HSBC bank has moved all its 65 SQL databases into a single MongoDB.

https://diginomica.com/hsbc-moves-65-relational-databases-on...

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#104

Post by fhunt »

cies wrote: post #38

Just did some POCs with Hasura, a service on top of PG that provides: * GraphQL interface (I think even a REST one in the latest release) * authorization (role based) * API gateway (put other API behind your GraphQL interface) * a UI for managing the schema * a way to do mirgations Now GraphQL provides a schema (that includes the types of of the values), that can be used to generate clients libs in many languages. Th…

While Hasura is nice, it's too much blackbox, too much all-in, too much risk, we decided against it.

2021 is great because of TypeScript, types and decorators (just put here any other typed lang with decoraters if you do not like TS). If your db is your leading system for your schema, everything else is derived and "code-generated" with all the restrictions SQL has. Which is not great if you want to decorate and enhance. Yes, you could use interfaces but it's not the same, you can't decorate code-generated type definitions but your architecture wouldn't stay DRY either.

If you think TS' types as the leading schema you do not need a type checked db like Postgres anymore, anything which can store data works just fine you have all schema definitions at one place which is not the DB. Good examples enabling such an architecture are TypeORM and TypeGraphQL. However most stick to SQL and 'my schema must be in my DB, there is no other way to enforce a schema' (but there is!) you just need a good architecture (types and decorators!) and not another mainstream-from-the-shelf-solution.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#105

Post by twic »

bildung wrote: post #17
menzoic wrote: post #11

Earlier quoted context omitted.

What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?

In what scenarios does one work on data without any relations? Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

I will pedantically note that in database theory, "relation" is a name for what we usually call a table. You're talking about relationships.

https://en.wikipedia.org/wiki/Relation_(database)

If your data is completely flat, and fits in one table, that's still a relation!

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#106

Post by richardw »

aidos wrote: post #35
Twisell wrote: post #8

Earlier quoted context omitted.

The top comments of this old thread are retrospectively hilarious because sone frontend guys argues about wether SQL is not easily composable and exchanges trick about how you can securely and dynamically concatenate SQL statements. But nowhere to be found is the concept of prepared statements that would gracefully help then write nicer code. https://www.postgresql.org/docs/current/sql-prepare.html And that is a ligh…

I was involved in those original discussions and it was just the standard “how to manipulate sql” discussion. Prepared statements don’t help you here, right? My understanding is that they’re purely for performance as the parser doesn’t need to be rerun each time. You need to recreate them for every dB session.

No sql injection, can set permissions for each proc, isolates app from DB implementation so you don’t have to redeploy app. Eg you can migrate older data to an archive table and query it on certain circumstances. App doesn’t need to know.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#107

Post by qaq »

whitepoplar wrote: post #21
qaq wrote: post #9

What surprises me is that so far none shoehorned Postgres on top of FoundationDB.

I'm not familiar with FoundationDB. What benefit would that give Postgres?

It would become distributed DB on top of super solid foundation that powers snowflake, icloud etc.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#108

Post by bildung »

twic wrote: post #105
bildung wrote: post #17

Earlier quoted context omitted.

In what scenarios does one work on data without any relations? Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

I will pedantically note that in database theory, "relation" is a name for what we usually call a table. You're talking about relationships. https://en.wikipedia.org/wiki/Relation_(database) If your data is completely flat, and fits in one table, that's still a relation!

TIL, thanks :)

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#109

Post by twic »

eicnix wrote: post #57
bildung wrote: post #17

Earlier quoted context omitted.

In what scenarios does one work on data without any relations? Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

Financial data In basically every case you are querying all data for a symbol in a given timeframe and then process it further outside of the database.

But a relational database is great for that.

  select *
  from prices
  where symbol = any (?)
  and timestamp >= ?
  and timestamp
I've worked at a couple of places where we kept price data in relational databases and did pretty much this.

The only way to beat a relational database here would be in performance. Because of course, for a specific use-case, you can always write a specialised data store that is faster than a general-purpose one. But the performance advantage might not be enough to justify the cost. If you're talking about storing every tick on an exchange, it might be, but if you're storing close prices, probably not.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#110

Post by mschuster91 »

dheera wrote: post #33
bildung wrote: post #17

Earlier quoted context omitted.

In what scenarios does one work on data without any relations? Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

When you get piles of JSON data from somewhere else (e.g. an API response from a provider you subscribe to) and want to store all of it intact, query it, and that somewhere else may insert new fields at any time in the future without telling you. When you have multiple types of objects with differently populated fields that you want to store in a single collection and query across them in currently unknown ways, and…

> and that somewhere else may insert new fields at any time in the future without telling you.

That's what interface contracts and API versioning is for - and new fields shouldn't be any problem at all unless you're parsing the JSON by hand.

Post reply on HN