Live data from Hacker News

PostgreSQL is enough

gist.github.com

61–70 of 323 posts

Re: PostgreSQL is enough

#61
No it's not, because it's very hard to set up in clustered HA environments. This is 2024. It should be possible to just add database nodes.

Re: PostgreSQL is enough

#63

This makes a strong case, but I've decided to start every new project with sqlite and not switch until absolutely necessary. If Postgres is the 90% case, then sqlite is the 80% case and is also dead simple to get going and genuinely performant. So when vertical scaling finally fails me, I know I'll be at a wonderful place with what I'm building.

I’m with you in general, but what about vector search? It really feels like the DB industry has taken a huge step backward from the promise of SQL. Switching from Postgres to SQLite is easy because the underlying queries are at least similar. But as soon as you introduce embeddings, every system is totally different (and often changing rapidly).

Vector similarity searches can be done with simple SQL statements, and while the performance will not match a vector db, it's often good enough. For a db like SQLite that can run in-memory, I suspect they would be reasonably fast.

Re: PostgreSQL is enough

#64

This makes a strong case, but I've decided to start every new project with sqlite and not switch until absolutely necessary. If Postgres is the 90% case, then sqlite is the 80% case and is also dead simple to get going and genuinely performant. So when vertical scaling finally fails me, I know I'll be at a wonderful place with what I'm building.

I’m with you in general, but what about vector search? It really feels like the DB industry has taken a huge step backward from the promise of SQL. Switching from Postgres to SQLite is easy because the underlying queries are at least similar. But as soon as you introduce embeddings, every system is totally different (and often changing rapidly).

There are vector search solutions for sqlite that basically work, so if my project doesn't rely on that 100% then I'm willing to use those as stop-gaps until it does.

Of course, if there's a shortcoming of sqlite that I know I need right out of the gate, that would be a situation where I start with postgres.

Re: PostgreSQL is enough

#65
post #27

On the [Simplify: move code into databases]( https://sive.rs/pg ), has anyone actually tried this? My instinct is that the output won't be simpler at all, but a big twisty web of varying parts and competing use cases, all extremely hard to discover. To me, having two things that do something distinct is simpler, and ironically, Rich Hickey says this exact thing in Simplicity Matters, which is quoted in the article.

One caveat is when you have to upgrade across major database versions. The more your application utilises these features, the more you're likely to hit when next major version upgrade has to happen. Not that major database versions are any simpler even if you just stick to CRUD for databases.

> Not that major database versions are any simpler even if you just stick to CRUD for databases.

I mean, even LTS versions have EOL dates, so even at the least frequent, you'll need to do upgrades around every 5 years or so.

Re: PostgreSQL is enough

#66
post #41

Earlier quoted context omitted.

Not sure why this is making people upset.

Because it's incorrect. If you have any non-postgres side-effect, you can't have exactly-once (unless you do 2PC or something like that). There isn't any technology that gives you "exactly once" in the general case.

That's not how exactly once is defined for queue. We are talking about semantics of what queue systems is providing.

Re: PostgreSQL is enough

#67
There is a lot here that I find useful. Mastering multiple technologies: html, node, JavaScript, SQL, CSS - grids and flex, blah, blah, blah is simply impossible. Developing a working set of knowledge is not. The problem is that you don't know what you should know.

A working set raises another set of issues: how do the pieces relate? What is the proper role of each technology?

This gist is extremely useful to me both in helping me to understand more of what I need to know. The article https://sive.rs/pg was very helpful as one way to think about how postgresql could and should fit in.

Re: PostgreSQL is enough

#68
post #49
post #25

Earlier quoted context omitted.

SQS is at least once PG can give you exactly once

SQS FIFO has exactly-once processing

well that's a stretch it has "5 minute window" You can hold a lock on a row in PG queue for as long as you need

Re: PostgreSQL is enough

#69
post #5

Love postgres and use it extensively. However, there's always an issue when I start doing the more advanced stuff: how do I combine that with all my years of experience with version control, code reviews, types, tests, static analysis and all the niceties of coding in general? Migrations?

It's not a great DX for sure. Once you start stuffing a ton of application logic in Postgres triggers (or worse split logic between your application layer and triggers) your system will explode in complexity really fast. Developers will insert a row in an inconspicuous table and things will break in ways that seem mysterious because it's not obvious, looking at the application code, why the system is misbehaving.

There are commands in most postgres clients, even psql, to view the _currently_ defined functions... but when you go to debug those you will have to look through migrations to see how the function came into it's current state... bisecting through history here is not very useful since each change to the function is a new file. I think this can be fixed though and made much easier, it's just not there yet.

In general I don't think the developer tooling is up to par to push very much of your application logic into postgres itself. I recommend using triggers for consistency and validation or table-local updates (ie: timestamps, audit logs) but keep process-oriented behaviour (iow: when this happens, then that, else this, wait for call and insert here, etc) in the application layer (chasing a cascade of triggers is not fun and quite annoying).

... all that being said, you can do unit testing in Postgres. And there is decent support for languages other than pgSQL (ie: javascript, ocaml, haskell, python, etc). It's possible to build dev tooling that would be suitable to make Postgres itself an application development platform. I'm not aware of anyone who has done it yet.

Re: PostgreSQL is enough

#70

Was talking to coworker yesterday about a spectrum of where code lives, and the differences from where I started to where I am now in understanding. Start after college and backend web dev was fully in scripting language, Python or Ruby, and ORMs that completely fogged where any of the data was stored. Rails and ActiveRecord is so good at shrouding the database to the point where you type commands that create databas…

>....backend web dev was fully in scripting language, Python or Ruby...

Not on my bubble, it has been fully in .NET and Java since 2001, with exception of a couple of services written in C++.

Post reply on HN