On Mon, 11 Mar 2019 at 12:36, Michael Nolan <htfoot@xxxxxxxxx> wrote: > There isn't a simple answer to this, it's like asking 'which is better for cooking: aluminum or stainless steel'. The answer is 'it depends on what you're trying to do'.i Metaphors can be dangerous (especially when automotive ones get chosen!), but this is a pretty good one. Often, it doesn't terribly much matter which kind of cookware you use; both aluminum and steel will allow you to cook your dinner, and if your needs are not challenging, the differences may make little difference. That seems likely to be true here; both Postgres and MySQL have a sizable set of relatively common facilities where they would function in broadly similar ways. This wasn't so true in the MySQL 3 versus PostgreSQL 6 days, when they had enormously different expressions of basic usage patterns. (e.g. - in MySQL, you'd get data eaten by weak data types, or performance killed when writes demand full table locks, but PostgreSQL would lose performance when VACUUM would lock the whole table). Modern MySQL is a lot less sloppy than it used to be, and Modern PostgreSQL performs a way lot better than it used to. And you can certainly fry bacon in either a steel or aluminum pan; performance of that is liable to depend more on the qualities of stove and of the bacon than on the qualities of the fry pan. Paralleling the notion that performance and reliability might depend more on the qualities of the server, between CPUs, amounts and speed of RAM, and whether you're persisting data on SSDs versus "spinning rust disks." If your disk dies, the database goes away, "poof," irrespective of what brand of database you're using... It is also somewhat foolish to get deep into minutiae when we have no idea which details do or do not matter for the particular situation. It's pretty likely that there *is* some relevant minutiae, but, when the only details given are: - Retail company - DB size ~30GB - Present database is DB2 That doesn't point all that readily at "relevant minutiae". Sorts of things that might help: - What kinds of data types are in use? - What is the architecture of the system in practice? - What kinds of transaction load are being thrown at the system? - Presumably some OLTP activity to record retail activities - Reporting on activities (which might involve replication?) - Data lifecycles (how does data arrive, how does it exit once irrelevant?) There are consulting organizations out there that would be quite prepared to help with that sort of analysis. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
