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

How to use Postgres for everything

github.com

Post reply on HN
Print view View original

21–30 of 181 posts

Re: How to use Postgres for everything

#21

Post by szundi »

underdeserver wrote: post #11
whateveracct wrote: post #7

Just don't use a single Postgres DB for everything as you scale up to 100+ engineers. You'll inevitably get database-as-the-API. Now if you have the actual technical leadership [1] to scale your systems by drawing logical and physical boundaries so that each unit has its own Postgres? Yeah Postgres for everything is solid. [1] Surprisingly rare I've found. Lots of "successful" CTOs who don't do this hard part.

Drop the scare quotes from "successful". These guys shipped products. The migration to multiple databases, syncing user information etc. is a milestone, not a necessity at every step.

Thank you

Re: How to use Postgres for everything

#22

Post by RedShift1 »

jensneuse wrote: post #16

I absolutely love Postgres, but please allow me to say that you absolutely don't want to expose an API generated from a database to people outside of your team. This limits you a lot in changing the way you store your data. I wrote about this topic before and haven't changed my opinion much. You don't want to have that tight coupling: https://wundergraph.com/blog/six-year-graphql-recap#generate...

What exactly is the problem with tight coupling? You're going to insert an entire layer that basically translates format A to format B, just so you can later change a column name in the database and not have to change it in the API or something?

Re: How to use Postgres for everything

#23

Post by szundi »

anonzzzies wrote: post #19
whateveracct wrote: post #7

Just don't use a single Postgres DB for everything as you scale up to 100+ engineers. You'll inevitably get database-as-the-API. Now if you have the actual technical leadership [1] to scale your systems by drawing logical and physical boundaries so that each unit has its own Postgres? Yeah Postgres for everything is solid. [1] Surprisingly rare I've found. Lots of "successful" CTOs who don't do this hard part.

You don't have to plan this very early; most companies won't get to 100+ engineers. Let's ship first and worry about this, much much much much later. Overarchitecting stuff makes life hard; coming into companies that have 40 servers running with everything architected for 1000000 engineers and billions of visitors while in reality there aren't even 2 users and there is 1 overworked engineer. Stop doing that and stop…

If you die before that, it was the market, not engineers being slow. Of course. Or sales.

Re: How to use Postgres for everything

#24

Post by szundi »

feverzsj wrote: post #17
jjallen wrote: post #14

Earlier quoted context omitted.

I always wonder if postgrest works well after growing quite a bit. I really should google the largest companies using it.

In my experience, without careful tunning, postgres performance starts dropping significantly around 10 million rows.

We have billions of rows with clustering on one instance, perfect, half a rack almost.

Re: How to use Postgres for everything

#25

Post by qaq »

whateveracct wrote: post #7

Just don't use a single Postgres DB for everything as you scale up to 100+ engineers. You'll inevitably get database-as-the-API. Now if you have the actual technical leadership [1] to scale your systems by drawing logical and physical boundaries so that each unit has its own Postgres? Yeah Postgres for everything is solid. [1] Surprisingly rare I've found. Lots of "successful" CTOs who don't do this hard part.

database as API works fine if you have properly abstracted things with sprocs and views. It will be also far less brittle than 100 services exposed as GraphQL

Re: How to use Postgres for everything

#26

Post by haileys »

RedShift1 wrote: post #22
jensneuse wrote: post #16

I absolutely love Postgres, but please allow me to say that you absolutely don't want to expose an API generated from a database to people outside of your team. This limits you a lot in changing the way you store your data. I wrote about this topic before and haven't changed my opinion much. You don't want to have that tight coupling: https://wundergraph.com/blog/six-year-graphql-recap#generate...

What exactly is the problem with tight coupling? You're going to insert an entire layer that basically translates format A to format B, just so you can later change a column name in the database and not have to change it in the API or something?

Yes. A lot of the work I've done through my career is essentially this, once you boil away the rest of the details.

Re: How to use Postgres for everything

#27

Post by anon3459 »

lokimedes wrote: post #13

Having just spent the better part of two weeks integrating Apache Age for Graph data, just to realize the project is stale and a mess, don’t take this list on face value. Now hoping for better results with DGraph, but it seems that graph databases are living a precarious existence.

Haaaa same here for apache age. Can you elaborate a little please

Re: How to use Postgres for everything

#28

Post by [deleted] »

RedShift1 wrote: post #22
jensneuse wrote: post #16

I absolutely love Postgres, but please allow me to say that you absolutely don't want to expose an API generated from a database to people outside of your team. This limits you a lot in changing the way you store your data. I wrote about this topic before and haven't changed my opinion much. You don't want to have that tight coupling: https://wundergraph.com/blog/six-year-graphql-recap#generate...

What exactly is the problem with tight coupling? You're going to insert an entire layer that basically translates format A to format B, just so you can later change a column name in the database and not have to change it in the API or something?

[deleted]

Re: How to use Postgres for everything

#29

Post by grey-area »

RedShift1 wrote: post #22
jensneuse wrote: post #16

I absolutely love Postgres, but please allow me to say that you absolutely don't want to expose an API generated from a database to people outside of your team. This limits you a lot in changing the way you store your data. I wrote about this topic before and haven't changed my opinion much. You don't want to have that tight coupling: https://wundergraph.com/blog/six-year-graphql-recap#generate...

What exactly is the problem with tight coupling? You're going to insert an entire layer that basically translates format A to format B, just so you can later change a column name in the database and not have to change it in the API or something?

1. You don’t want or need to expose lots of implementation details. Many of your data structures should be private, and many should be partly private.

2. Your data structures should not dictate the shape of your api, usage patterns should (e.g. the user always needs records a,b,c together or they have a and want c but don’t care about b)

3. It stops you changing any implementation details later and/or means any change is definitely a breaking change for someone.

Re: How to use Postgres for everything

#30

Post by hmottestad »

RedShift1 wrote: post #22
jensneuse wrote: post #16

I absolutely love Postgres, but please allow me to say that you absolutely don't want to expose an API generated from a database to people outside of your team. This limits you a lot in changing the way you store your data. I wrote about this topic before and haven't changed my opinion much. You don't want to have that tight coupling: https://wundergraph.com/blog/six-year-graphql-recap#generate...

What exactly is the problem with tight coupling? You're going to insert an entire layer that basically translates format A to format B, just so you can later change a column name in the database and not have to change it in the API or something?

Normalization is one of those typical issues where you might be fine with having everything normalized when you start off, but then once performance gets bad you end up denormalizing tables that are typically joined.
Post reply on HN