No it's not enough eg for dense grid data you find in numerical simulations.
PostgreSQL is enough (2024)
81–90 of 97 posts
Re: PostgreSQL is enough (2024)
#82Is it recomended for beginers?
I think so. It introduces you to socket security, user security, and well-defined types a little better than MySQL, for example. Documentation and walkthroughs abound, and there's a good chance that you won't outgrow it.
> well-defined types a little better than MySQL
Ugh yes. I remember starting on MySQL then being hit by the strictness of Postgres... then terrified by the looseness of MySQL when I moved back (changing jobs).
Re: PostgreSQL is enough (2024)
#83While I love postgres, I take issue with coupling too much application logic to the DB. It’s much easier to update/rollback stateless containers/cloud functions/VMs than to recover a DB.
Why is it easier? You don’t need to operate on the entire database. You can backup or roll back individual tables and schemas.
You can do it, but if you stuff that process up (e.g. touch the wrong tables/schemas) you’re now dealing with a more complex recovery.
Also are you applying migrations with CREATE OR REPLACE etc? I find that much harder to collaborate on than just standard code.
Re: PostgreSQL is enough (2024)
#84Re: PostgreSQL is enough (2024)
#85I'd go further, and say that most of the time, "SQLite is enough". But, yes, PostgreSQL is all I ever use for anything that needs to be big. I ported a big old web app that had ScyllaDB, Elastic Search, Redis, and probably some other stuff I've forgotten. It got PostgreSQL+PostGIS (it's a mapping app), that's it. I'm sure there's some situation where it would be worth looking at all that other stuff, but it's ridicul…
I agree, the reason why I had submitted this HN submission post was because I was getting way too deep into the weeds of new databases like surrealdb/tigerbeetle/scylladb etc.
which while are an interesting problem to think through because well, it makes me feel smarter knowing these databases. I still felt like postgresql was enough, (at best something like clickhouse or redis combined with postgresql might be more than enough for many things)
But the fact of the matter is that sometimes you don't even need postgresql. I actually just deploy sqlite apps in golang/rust, a website that I had made that is a single binary: https://mirror.forum
Sqlite is more than enough as well and there are a lot of people pushing sqlite above its weight as well (Turso and the likes)
but its nice knowing that Sqlite/postgresql are more than enough for many use cases. Both are really amazing for a lot of things :-D
Its amazing how we've for the most part atleast now simplified the architecture to have good options. Like using Sqlite and especially Postgresql in the start is a decision that you would rarely go wrong at. I personally feel like although I use sqlite a lot more in projects because i value the simplicity it gives but postgresql also holds a somewhat good relationship in my heart :-D
Re: PostgreSQL is enough (2024)
#86Postgres has its advantages, but for message queues I’d stick with SQS. I built out a trading firm last year that was basically Postgres, some dotnet services and SQS queues and we got acquired for $140M. You can build some fairly formidable systems if you keep them simple.
As @f3408fh has said, I am also curious to knowing more about it if possible.
I had always thought that trading firms might be some of the sole exceptions of over-engineering as I had went into the rabbit-holes of FPGA's and found that some of the use-cases of that technology was trading firms using it to literally shave off even a few milliseconds and so the amount of optimization there
So I am a bit curious how postgres/some dotnet services and SQS queues is able to create a trading firm and scale it and even sell it for 140M$. It feels like my understanding of the situation was a bit uncertain then but could you please elaborate more if possible?
Re: PostgreSQL is enough (2024)
#87Earlier quoted context omitted.
You don't want to know what kind of bugs ( massive bugs) you'd run into.
Can you say more about those bugs?
I think this is a joke referencing Franz Kafka's short story The Metamorphosis: https://en.wikipedia.org/wiki/The_Metamorphosis
Re: PostgreSQL is enough (2024)
#88Earlier quoted context omitted.
These are not bad decisions they are reasonable tradeoffs at the beginning. Requiring HA, partitioning, and replication are good problems to have. The alternative is spending engineering time on setting all these up for a failed service with like 100 users.
It is not good to have a problem that requires a year of migration by a dedicated team (typical case if you have this 'good problem') when you could have simply spent another day or two to architect it right. You should at least have a path to scale when the time comes.
Deploying HA, partitioning, and replication requires much more than a day or two especially from a team that has not deployed such a system before. And then it requires constant monitoring.
Re: PostgreSQL is enough (2024)
#89Postgres has its advantages, but for message queues I’d stick with SQS. I built out a trading firm last year that was basically Postgres, some dotnet services and SQS queues and we got acquired for $140M. You can build some fairly formidable systems if you keep them simple.
Sounds interesting. Can you elaborate? You got acquired one year into doing business for 100M+? Impressive
Sorry, that's not entirely accurate - we started in 2024 and were acquired in 2025, so it was just under two years.
Re: PostgreSQL is enough (2024)
#90Postgres has its advantages, but for message queues I’d stick with SQS. I built out a trading firm last year that was basically Postgres, some dotnet services and SQS queues and we got acquired for $140M. You can build some fairly formidable systems if you keep them simple.
As @f3408fh has said, I am also curious to knowing more about it if possible. I had always thought that trading firms might be some of the sole exceptions of over-engineering as I had went into the rabbit-holes of FPGA's and found that some of the use-cases of that technology was trading firms using it to literally shave off even a few milliseconds and so the amount of optimization there So I am a bit curious how pos…
I'm generalizing a bit, we built a trade-surveillance system that integrates with various trading terminals.