Obligatory parody link: https://youtu.be/HdnDXsqiPYo
Talking to AI 12 years ago :-)
The Great Migration from MongoDB to PostgreSQL
301–310 of 339 posts
Re: The Great Migration from MongoDB to PostgreSQL
#302The one unsolicited piece of tech advice I always give is “Just use Postgres”. Postgres Is Enough: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f... There’s some Mongo/json alternatives in the list if you really need unstructured data. And there’s a huge plug-in ecosystem as well for just about anything you could imagine.
But isn't there a point before which "just use sqlite" is more appropriate advice?
For server applications I don't think so (despite the recent hype driven by businesses marketing the cloud services). Managing multiple writes and durability needs the same or even more effort and attention than running PG or MySQL. And on top of it SQLite is missing many often crucial features. For me, those are the type system and functions.
Re: The Great Migration from MongoDB to PostgreSQL
#303Earlier quoted context omitted.
Postgres 8 supported functions capable of returning tuples (RETURN QUERY), but lacked transaction control and other features that CREATE PROCEDURE added in Postgres 11 (2018). Extensions in Postgres 8 (and earlier) were also half-baked compared to 9.1 (2011), which added CREATE EXTENSION and other quality-of-life improvements including standardization. The latest complete implementations are what most people have in…
Sure, there are improvements, but it's not like Postgres was a radically different beast back then. Would I pick Postgres 15 over Postgres 8? Yes, any day of the week. But I would also readily pick Postgres 8 over most of today's databases (including e.g. the latest MySQL and MongoDB versions), for most projects, if that was the choice I had.
I would not have risked my business (or budget) on Postgres 8, even with Slony-I. My appreciation for its well-written code and thoughtful architecture simply did not outweigh what it lacked for a reliable operations experience.
MySQL foot guns were mostly under control by 2010, and it was operationally efficient to manage a cluster of MySQL servers in diverse configurations with mostly-known boundaries to what could go wrong.
The Postgres foundations are the same today, but what you can build on top is very different today than it was pre-9.x.
Re: The Great Migration from MongoDB to PostgreSQL
#304Earlier quoted context omitted.
I remember Robert C. Martin ("Uncle Bob") going on about how No-SQL will replace literally all SQL and that there is literally not a single use case for relational data and SQL. I wonder if he ever came back on that. Now, my opinion of Martin in general is not especially high and he's a bit of a controversial figure, but it wasn't just the kids. And Martin is also all about reliable software, so that makes it even mo…
His words: "I am also self-taught. I never got a degree of any kind. I entered the industry at the tender age of 17 and never looked back. Frankly, school isn’t all it’s cracked up to be — especially in the software field." https://twitter.com/unclebobmartin/status/107212575854868889... Which means his opinions are more often than not uninformed opinions and should be taken with a grain of salt.
I think you overestimate college education a little too much. Having a degree doesn't make your opinions automatically better than those that didn't have the chance to get one. You wish it did, but it don't.
Re: The Great Migration from MongoDB to PostgreSQL
#305Earlier quoted context omitted.
Sure, there are improvements, but it's not like Postgres was a radically different beast back then. Would I pick Postgres 15 over Postgres 8? Yes, any day of the week. But I would also readily pick Postgres 8 over most of today's databases (including e.g. the latest MySQL and MongoDB versions), for most projects, if that was the choice I had.
I would not have risked my business (or budget) on Postgres 8, even with Slony-I. My appreciation for its well-written code and thoughtful architecture simply did not outweigh what it lacked for a reliable operations experience. MySQL foot guns were mostly under control by 2010, and it was operationally efficient to manage a cluster of MySQL servers in diverse configurations with mostly-known boundaries to what could…
I operated MySQL clusters in the late 2000s. I still am surprised how many hoops you have to jump through to set up replication in PostgreSQL than what you could do - out of the box - with MySQL 15 years ago.
Re: The Great Migration from MongoDB to PostgreSQL
#306Earlier quoted context omitted.
Sure, there are improvements, but it's not like Postgres was a radically different beast back then. Would I pick Postgres 15 over Postgres 8? Yes, any day of the week. But I would also readily pick Postgres 8 over most of today's databases (including e.g. the latest MySQL and MongoDB versions), for most projects, if that was the choice I had.
I would not have risked my business (or budget) on Postgres 8, even with Slony-I. My appreciation for its well-written code and thoughtful architecture simply did not outweigh what it lacked for a reliable operations experience. MySQL foot guns were mostly under control by 2010, and it was operationally efficient to manage a cluster of MySQL servers in diverse configurations with mostly-known boundaries to what could…
> I would not have risked my business (or budget) on Postgres 8, even with Slony-I.
This assumes you need replication, though. You can get pretty far without it, especially given how wide hardware you can get now.
> MySQL foot guns were mostly under control by 2010
Eh. :-) I think you would have to specify which footguns in particular.
Re: The Great Migration from MongoDB to PostgreSQL
#307Earlier quoted context omitted.
What?? That's an insane argument. That's like saying if one client sets column X to 1 and another client concurrently sets SET y = 2, one client's writes will be LOST . It shouldn't, and it doesn't. If it did, nobody would use Postgres. This issue only exists with PG's JSON impl.
What?? That’s an insane way to describe what I’m talking about. Data/transaction isolation is very complex and extremely specific to every use case, which is why database engines worth anything let you describe to them what your needs are. Hence why when one client writes to Y they specify what they think X should be if relevant and get notified to try again if the assumptions are wrong. An advantage of specifying yo…
So updating one column on a table is destructive and can lose important information now? :D
How do you increment a value in a column while other people write to the database? You don't grab the whole damn row and rewrite it...
Re: The Great Migration from MongoDB to PostgreSQL
#308Earlier quoted context omitted.
What?? That's an insane argument. That's like saying if one client sets column X to 1 and another client concurrently sets SET y = 2, one client's writes will be LOST . It shouldn't, and it doesn't. If it did, nobody would use Postgres. This issue only exists with PG's JSON impl.
What?? That’s an insane way to describe what I’m talking about. Data/transaction isolation is very complex and extremely specific to every use case, which is why database engines worth anything let you describe to them what your needs are. Hence why when one client writes to Y they specify what they think X should be if relevant and get notified to try again if the assumptions are wrong. An advantage of specifying yo…
Also this statement:
> which is why database engines worth anything let you describe to them what your needs are
Contradicts your argument.
Mongo has atomic updates to update specific fields, or you can do replaceOne() etc to replace the whole document.
While PG only gives you "replace" with JSON.
So I guess postgres isn't worth anything. :)
Re: The Great Migration from MongoDB to PostgreSQL
#309Earlier quoted context omitted.
I would not have risked my business (or budget) on Postgres 8, even with Slony-I. My appreciation for its well-written code and thoughtful architecture simply did not outweigh what it lacked for a reliable operations experience. MySQL foot guns were mostly under control by 2010, and it was operationally efficient to manage a cluster of MySQL servers in diverse configurations with mostly-known boundaries to what could…
> I would not have risked my business (or budget) on Postgres 8, even with Slony-I. This assumes you need replication, though. You can get pretty far without it, especially given how wide hardware you can get now. > MySQL foot guns were mostly under control by 2010 Eh. :-) I think you would have to specify which footguns in particular.
Replication can be for HA, not just for scale. All depends on your business requirements.
Also replication can be good for other operational reasons, such as zero downtime major version upgrades. Again depends on the business need/expectations.
Re: The Great Migration from MongoDB to PostgreSQL
#310Earlier quoted context omitted.
I would not have risked my business (or budget) on Postgres 8, even with Slony-I. My appreciation for its well-written code and thoughtful architecture simply did not outweigh what it lacked for a reliable operations experience. MySQL foot guns were mostly under control by 2010, and it was operationally efficient to manage a cluster of MySQL servers in diverse configurations with mostly-known boundaries to what could…
> I would not have risked my business (or budget) on Postgres 8, even with Slony-I. This assumes you need replication, though. You can get pretty far without it, especially given how wide hardware you can get now. > MySQL foot guns were mostly under control by 2010 Eh. :-) I think you would have to specify which footguns in particular.
If you're doing tens of millions in revenue and the RDBMS is critical to your operations, I'm a firm believer you need replication. Keep in mind this was the era of spinning rust and a day-old backup could take hours to restore even with a SAN/DAS. A replica was for more than just distributing load, it was for resilience to keep the business healthy and avoid a SPOF.
Risks to the business are more important to me than my enthusiasm for a technology or product.