Live data from Hacker News

How to use Postgres for everything

github.com

121–130 of 181 posts

Re: How to use Postgres for everything

#121

I was recently annoyed to find postgres indexes don't support skipping [1] you also can't have the nul character in a string (\u0000) [2]. Its great, but it has some strange WTF gaps in places. [1] https://wiki.postgresql.org/wiki/Loose_indexscan [2] https://stackoverflow.com/questions/28813409/are-null-bytes-...

What is a reasonable use for a null character in a string? My first instinct is that strings with nulls in them should absolutely be rejected.

Yup. It's a huge red flag when a datatype intended to be used for representation of written human language is abused to store something that has no glyph recognisable in any human language.

There's a lot to complain about with nul-terminated strings, but not being able to store arbitrary bytes ain't one of them.

Re: How to use Postgres for everything

#123
post #25

Earlier quoted context omitted.

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

Stored procedures just add overhead and make everyone's lives harder. Forget about any ORMs, you're writing raw SQL with all the quirks of PL/pgSQL biting you all the time.

There's advantages too:

- marking some columns as NOT NULL.

- referential integrity means you can't accidentally have dangling pointers to non-existant dat.

- mutually exclusive columns let's the database enforce things like "at least one of A and B needs to be Nonzero, and both cannot be Nonzero at the same time.

- create a type that allows only values matching a specific regex.

Seriously, if you want strong typing across composite data, there isn't a language invented yet that comes even close to a RDBMS.

Of course the majority of Devs don't know any of this because their ORM doesn't expose any of this; it gives them a way to store and query tabular data, and nothing else.

Re: How to use Postgres for everything

#127
post #47

[flagged]

If you’re going to make a ragebait comment you should ideally provide some kind of basis beyond “waaaah everybody except me is stupid”

You should find your reading glasses and read what actually is written.

When you do find your reading glasses, the links below might be helpful.

https://en.wikipedia.org/wiki/TiDB https://en.wikipedia.org/wiki/YugabyteDB

https://ydb.tech/

Re: How to use Postgres for everything

#128
post #80

Earlier quoted context omitted.

If you don't have any discipline it becomes hell. Not to mention that a random team writing a migration that locks a key shared table (or otherwise chokes resources) now causes outages for everyone .

Not a problem until it's a problem.

"Until it's a problem" is doing a lot of heavy lifting in your sentence. For 99% of projects that "until" will never come.

Re: How to use Postgres for everything

#129

Earlier quoted context omitted.

Stored procedures just add overhead and make everyone's lives harder. Forget about any ORMs, you're writing raw SQL with all the quirks of PL/pgSQL biting you all the time.

There's advantages too: - marking some columns as NOT NULL. - referential integrity means you can't accidentally have dangling pointers to non-existant dat. - mutually exclusive columns let's the database enforce things like "at least one of A and B needs to be Nonzero, and both cannot be Nonzero at the same time. - create a type that allows only values matching a specific regex. Seriously, if you want strong typing…

None of this prevents you from doing both inside the DB _and_ the app. That way you cover your bases that (1) your app is sound and has maximum amount of fail-early validations to avoid corrupted data states and (2) even if somebody decides to skip the app and try to be clever in a psql console they'll still not be able introduce corrupted data states and (3) leave the door open for other apps to be able to connect to the same DB and do stuff (or simply to allow for a rewrite in another language).

Re: How to use Postgres for everything

#130

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?

The extremely obvious problem is that how you store data is an implementation detail and those change when requirements (or the market) evolve. I'll give you an API and will make triple sure it's as fast as a machine can even serve it and you let me worry about how it's all stored.

To additionally answer you with an analogy: when you have a problem with a company, you call the call center, not Jenny from accounting in particular. Jenny might have helped you twice or thrice but she might leave the company next year and now you have no idea how to solve your problem. Have call centers to dispatch your requests wherever it's applicable in the given day and leave Jenny alone.

Post reply on HN