MongoDB is like snapchat for database
Would've been funnier and timely about a decade ago.
MongoDB would have been timely about a decade ago.
Goodbye MongoDB, Hello PostgreSQL (2015)
111–120 of 172 posts
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#112Earlier quoted context omitted.
I'm sorry you had to go through that.
Oh please, quit the bullshit elitism. I think postgres is a way more robust solution than mongo, but I've had my worst db experiences having to deal with a postgres db with almost all the business logic in triggers. That was a huge pain in the ass to maintain and understand. Mongo is defnitely a limited solution, but for certain cases it just works pretty well, with less complexity than postgres. At one of my jobs, I…
You suffered because of idiot co-workers.
Let me tell you, your idiot co-workers can also do some evil things in Mongo pipelines.
Very, very evil things.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#113Earlier quoted context omitted.
The top comments of this old thread are retrospectively hilarious because sone frontend guys argues about wether SQL is not easily composable and exchanges trick about how you can securely and dynamically concatenate SQL statements. But nowhere to be found is the concept of prepared statements that would gracefully help then write nicer code. https://www.postgresql.org/docs/current/sql-prepare.html And that is a ligh…
Correct me if I'm wrong, but I think you missed the point of the discussion? It is not connected to frontend at all. It talks about the difference between using an ORM versus constructing SQL statements directly, as strings. In that light I don't think `PREPARE` and stored procedures would help much (or at all). I also don't find them hilarious, though they do represent very extreme views on the subject (imho) while…
My point is precisely that they compare two subpar approach of SQL while prepared or stored procedure are the real contender here.
And as far as I understand depending on your use case prepared or stored is better.
Prepared mean less code base inside the db and still more composability with less sql injection risks.
Stored add even more composability and security but at the cost of managing code inside the db.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#114Earlier quoted context omitted.
The top comments of this old thread are retrospectively hilarious because sone frontend guys argues about wether SQL is not easily composable and exchanges trick about how you can securely and dynamically concatenate SQL statements. But nowhere to be found is the concept of prepared statements that would gracefully help then write nicer code. https://www.postgresql.org/docs/current/sql-prepare.html And that is a ligh…
I was involved in those original discussions and it was just the standard “how to manipulate sql” discussion. Prepared statements don’t help you here, right? My understanding is that they’re purely for performance as the parser doesn’t need to be rerun each time. You need to recreate them for every dB session.
I'm not familiar enought with the execution context, i could be wrong and i totally get that theses are examples while final code would probably include escaping checks. But that being said some of the proposed solutions could probably lead to a little bobby table situation...
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#115Earlier quoted context omitted.
> Eg. Dump all of the data to S3 and search it in parallel via AWS Athena. Too proprietary. Can't be run locally, on robots, etc. Can't be transferred to other cloud providers. Also S3 is horribly slow to write or delete thousands of records at once.
> Too proprietary. Every major cloud provider has a blob store. Most are S3-interface compatible, or can be fronted by something which is, like Minio. > Can't be run locally, on robots, etc. If the contents of your S3 keys are just line-delineated JSON files, you can easily download those files and run scripts or process them locally. > Can't be transferred to other cloud providers. Again, not true — a tool like rclo…
> Also S3 is horribly slow to write or delete thousands of records at once.
I'll add that S3 is only slow to delete things sequentially. You can delete or write an effectively infinite amount of items in parallel.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#116Is there a situation where I SHOULDN'T use Postgres?
Postgres is incredibly flexible and scales beyond what most projects will ever need. We use it both as a very large scale CMDB store for https://turbot.com and as an small embedded DB for https://steampipe.io.
Use cases where we hit road bumps earlier were:
1. High churn data. Postgres copies data for each rite update and then vacuums to clean the old versions. These use cases dominated our DB load and moving them out helped a lot.
2. Large JSON blobs. Postgres automatically compresses and will pull large (~>8kB) columns into a separate “toast” table. This makes sense but also means they are often a real bottleneck if you expect to work with larger JSON blobs as you core model. pg is great for JSON, but if you are using it at scale do pre-work and testing of this factor and how it plays with your model.
3. Of course, long term archive of data objects is much more cost efficient and scalable in an object store like S3.
Bet on Postgres. Whatever you use case it will work great until you are large enough to really understand your data and optimize for your business.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#117Earlier quoted context omitted.
When you are creating MVPs time matters the most. You are anyway going to throw it away and build something better. I was using Mongo and NodeJS a lot but then switched to Python. Now I find the world of ORMs to be onerous. I just want to define tables in MySQL and just run raw SQLs. The best compromise I have found so far. I mean it does involve boiler plate code but ultimately it's an MVP. And you are right, most o…
I also moved away from NoSQL for prototyping; as I recount in the sibling comment, I think the touted increase in dev speed is a myth, as the only penalties in dev speed for SQL come from (a) learning the tech and (b) thinking of your data model ahead of time, both fixed costs which dilute over time and eventually make you faster. > Now I find the world of ORMs to be onerous Funnily enough, I've also moved to Python,…
I have not tried the Django ORM. Most of my backend is REST services so I use FastAPI with SQLAlchemy. SQLAlchemy + pydantic is a bit onerous I feel.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#118Is there a situation where I SHOULDN'T use Postgres?
Postgres is incredibly flexible and scales beyond what most projects will ever need. We use it both as a very large scale CMDB store for https://turbot.com and as an small embedded DB for https://steampipe.io . Use cases where we hit road bumps earlier were: 1. High churn data. Postgres copies data for each rite update and then vacuums to clean the old versions. These use cases dominated our DB load and moving them o…
Even in cases for regional replication?
Because this is the use case I am looking for, something like Spanner but cheaper.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#119Just did some POCs with Hasura, a service on top of PG that provides: * GraphQL interface (I think even a REST one in the latest release) * authorization (role based) * API gateway (put other API behind your GraphQL interface) * a UI for managing the schema * a way to do mirgations Now GraphQL provides a schema (that includes the types of of the values), that can be used to generate clients libs in many languages. Th…
While Hasura is nice, it's too much blackbox, too much all-in, too much risk, we decided against it. 2021 is great because of TypeScript, types and decorators (just put here any other typed lang with decoraters if you do not like TS). If your db is your leading system for your schema, everything else is derived and "code-generated" with all the restrictions SQL has. Which is not great if you want to decorate and enha…
Interesting. My db and it's types have whole migration procedures to ensure all works on all environments, Hasura also does this.
How would that work with just-TS? The schema changes but the documents in my KV-store (I assume that what you mean by "no types on the storage") have not changed accordingly. How to prevent this obvious trouble?
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#120Earlier quoted context omitted.
I had a project where I just needed to be saving a constant flow of data (id + 100 bytes records) somewhere, no persistence needed, no sharding (single machine) - but lots of it. I first turned to Redis and it worked nicely, but since I had PostgreSQL running, I made a performance test with it too. To my surprise, once I optimized both (memory only, pg WAL disabled, persistent connections,...) there was almost no dif…
Your data-saving test was probably limited by how fast you could save to disk a roughly equal amount of data with the two databases; queries might work and perform more differently.
That's what I meant by "no persistence needed". In both cases, I wasn't actually saving anything to disk. I needed an in-memory storage for a never-ending stream of incoming data that would be read (and purged) by a separate process, no biggie if the data got lost occasionally.
I also simply inserted and read the data, no complex queries or anything. Key-value store is all I needed and for this particular case PostgreSQL was as good at it as Redis.