Live data from Hacker News

PostgreSQL is enough

gist.github.com

31–40 of 323 posts

Re: PostgreSQL is enough

#31
post #21

I often go down rabbit holes like this, trying to collapse and simplify the application stack. But inevitably, as an application grows in complexity, you start to realize _why_ there's a stack, rather than just a single technology to rule them all. Trying to cram everything into Postgres (or lambdas, or S3, or firebase, or whatever other tech you're trying to consolidate on) starts to get really uncomfortable. That s…

I think SQS is cheap enough to build on as a messaging queue even if you're not hosting within AWS. Out of the widely underrated AWS services include SNS and SES and they are not a bad choice even if you're not using AWS for compute and storage.

You get exactly once when you consume with pgmq and run your queue operations inside transactions in your postgres database. I can't think of an easy way to get some equivalent on SQS without building something like an outbox.

Re: PostgreSQL is enough

#32
One cool thing if you are running off Postgres - DDL is transactional so you get clean deploy of your new code version (stored procedures) with precise switchover for free.

Re: PostgreSQL is enough

#34
post #17

Could you write an OS based on PostgreSQL?:)

It depends on your definitions, but if you took psql and Postgres and compared it to something like an OS on a 1980s microcomputer, you're kinda there. You can run arbitrary commands, you can program it, you can debug those programs, you can run programs, and you can access storage. If you're talking more like Linux or Windows, you have.. a bit more work to do ;-)

Re: PostgreSQL is enough

#36
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 databases and you never see them. Classes are written to describe what we want the data to look like and poof! SQL commands are created to build the schema that we never need to see. On this end of the spectrum, the scripting language will stay the same, but we want to be agnostic to where the data is stored.

On on the other end of the spectrum, Postgres is enough. More than enough. Like in the link, it can do all the tasks you ever care about. The code you're writing for the backend / data is about data, not about the script. We care where it's stored, that it's clear the structure, the reads and updates are efficient. We can write all statements in SQL to create tables, functions, trigger, queues, and efficient read queries with indexes to make the data come back to the scripting language in the exact form that's wanted. On this end, we know and optimize how the data is stored, agnostic to the scripting language that uses the data.

I went from the first end of the spectrum to the second. Everything can be done in Postgres. Audibility, clarity, efficiency is much better there than in Python, is my position. The only thing holding it back is that people don't see development from the data side yet, and if you're deciding on tech, it's not easy to use a tech that people don't have as good of development ability yet. There are no Postgres bootcamps right now.

But There's more and more adoption of this I'm seeing, and the money and development of Postgres leads me to trust that it'll be around a very long time, only getting better. Posts about the power of databases, Postgres and some SQLite for example are becoming more and more common. It's a cool change to follow and watch grow.

Re: PostgreSQL is enough

#38

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).

Re: PostgreSQL is enough

#39

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.

> [...] sqlite is the 80% case and is also dead simple to get going and genuinely performant.

I don't understand this. PostgreSQL is ALSO dead simple to get going, either locally or in production. Why not just start off at 90%?

I mean, I get there are a lot of use cases where sqlite is the better choice (and I've used sqlite multiple times over the years, including in my most recent gig), but why in general?

Re: PostgreSQL is enough

#40
Well it is obviously not enough as most of these are addons. Most of these are already built into MariaDB.

Excerpt from the motivaion of "PostgreSQL HTTP Client":

> Wouldn't it be nice to be able to write a trigger that called a web service?

Rather you than me.

Post reply on HN