Horizontal scale of writes.
Citus would be alright if the HA story was better: https://github.com/citusdata/citus/issues/7602
Just use Postgres
71–80 of 238 posts
Re: Just use Postgres
#72There is absolutely no reason you can't make SQLite go all the way. Starting with it is the only thing that makes sense to me. It is certainly a higher performance solution in the fair comparison of a hermetically sealed VM using SQLite vs application server + Postgres instance + Ethernet cable. We're talking 3-4 orders of magnitude difference in latency. It's not even a contest. There are also a lot of resilience st…
Surprised to hear that losing 15 min of state is not a big deal in a banking context. I haven't worked with banks before, genuinely curious, how do they recover from something like this? Wouldn't this potentially destroy all transactions made in that time period?
At best this will increase the load on customer support with an associated reputational hit. At worst you will need to deal with questions from financial regulators.
In all cases, rubbish customer experience.
Re: Just use Postgres
#73Use what you know, ship useful stuff.
Re: Just use Postgres
#74> If you see a college student or fresh grad using MongoDB stop them. They need help. They have been led astray. I like this sentence way more than I should.
Fully agree. At that level, the justification for using MongoDB usually boils down to not wanting to deal with table schemas or SQL. In both cases, there are better alternatives.
Re: Just use Postgres
#75From the article, DynamoDB-likes are good IF: * You know exactly what your app needs to do, up-front But isn't this true of any database? Generally, adding a new index to a 50 million row table is a pain in most RDBs. As is adding a column, or in some cases, even deleting an index. These operations usually incur downtime, or some tricky table duplication with migration process that is rather compute + I/O intensive..…
You can also add add GSIs (with their caveats) without any re-work.
Re: Just use Postgres
#76Totally agree - I have tried many databases of all flavors, but I always come back to Postgres. HOWEVER - this blog post is missing a critical point.... the quote should be: ---> Just use Postgres AND ---> Just use SQL "Program the machine" stop using abstractions, ORMs, libraries and layers. Learn how to write SQL - or at least learn how to debug the very good SQL that ChatGPT writes. Please, use all the very powerf…
May I ask question about this part? "Push all your business logic into big long stored procedures/functions - don't be pulling the data back and munging it in some other language - make the database do the work!" From my courses I had at university, I've been led to believe that the current trend is doing hexagonal architecture, as that allows for better modularisation of the project and helps keep code clean over ma…
The model described in the parent comment is essentially using the database (in this case PostgreSQL, but any RDMS would do) as the hexagonal "core" in which adapters plug in to. This is a powerful pattern that works very well when you use the full features of the RDMS like constraints, triggers, views, etc. This does require "coupling" to the RDMS-specific features, which makes migrating to an alternative system difficult, but in practice this rarely happens if you choose a strong RDMS from the beginning.
You can certainly use the database as a "dumb storage" tool in the hexagonal architecture, that is, as just another adapter. But most of the time you'll end up re-creating RDMS features in poorly written/documented application code that has to interact with the database anyways. Why not just do it all in the database? With a RDMS core, hexagonal adapters can be pure functional components, making them much easier to reason about and maintain.
For more on this idea, and how to avoid pitfalls with the hexagonal pattern, I recommend reading Out of the Tar Pit [1]. It's a short but highly influential paper on "functional relational programming".
Re: Just use Postgres
#77Really just reads as an article reaffirming his own bias. For Mongo at least most of it is wrong.
- Secondaries are read replicas and you can specify if you want to read from them using the drivers selecting that you are ok with eventual consistency.
- You can shard to get a distributed system but for small apps you will probably never have to. Sharing can also be geo specific so you query for french data on the french shards etc lowering latency while keeping a global unified system.
- JSON schema can be used to enforce integrity on collections.
- You can join but this I definitely don’t recommend if possible.
- I personally like the pipeline concept for queries and wish there was something like this for relational databases to make writing queries easier.
- The AI query generator based on the data using Atlas has reduced the pain of writing good pipelines. Chat gpt helps a lot here too.
- The change streams are awesome and has let us create a unified trigger system that works outside of the database and it’s easy to use.
We run postgres as well for some parts of the system and it also is great. Just pick the tool that makes the most sense for your usecase.
Re: Just use Postgres
#78From the article, DynamoDB-likes are good IF: * You know exactly what your app needs to do, up-front But isn't this true of any database? Generally, adding a new index to a 50 million row table is a pain in most RDBs. As is adding a column, or in some cases, even deleting an index. These operations usually incur downtime, or some tricky table duplication with migration process that is rather compute + I/O intensive..…
50M rows is really not that much, I’d guesstimate an index creation to take single-digit minutes.
None of these operations I’d expect to cause downtime, or require table duplication or to be risky
Edit: to be fair, you’re right there’s footguns. Make sure index creation is concurrently, and be careful with column default that might take a lock. It’s easy to do the right thing and have no problem, but also to do the wrong thing and have downtime
Re: Just use Postgres
#79It's not worth pointing out the technical flaws in the post[1]. It is obvious the author does not have a strong grasp of the tools he is criticising. A better example of this style of post is Oxide's evaluation[2] for control plane storage that actually goes over their specific needs and context. [1] Ok, just one, Rick Houlihan is currently at MongoDB. [2] https://rfd.shared.oxide.computer/rfd/53
> It's not worth pointing out the technical flaws in the post[1]. It might help your argument if you pointed out a real technical flaw in the content of the post, and not an example of the author being mistaken about a stranger's first name.
sure. 1. sqlite can have more than 1 file when using wal mode. 2. You don't need to know your exact dyanmodb access patterns upfront, you can evolve the schema. again, not worth effort to point out more.
Re: Just use Postgres
#80I wish postgres had a library only mode that directly stored to a file like sqlite. That'd make starting development a lot easier since you don't have to jump through the hoops of setting up a postgres server. You could then switch to a "proper" DB when your application grows.