14 ms·
The part of Postgres we hate the most: Multi-version concurrency control
- umairshahid 3y agoHere is a rebuttal of many of the points raised by Uber against PostgreSQL: https://www.2ndquadrant.com/en/blog/thoughts-on-ubers-list-of-postgres-limitations/ https://www.2ndquadrant.com/en/blog/thoughts-on-ubers-list-o...
- Ym9oYW4 3y agoSo why Postgres chooses the worst MVCC design compared to MySQL and Oracle? Is this because of legacy reasons or other factors?
- apavlo 3y agoLegacy reasons. The idea was that you wouldn't need a WAL because the table itself is the log. And then you could support time-travel queries if you never cleaned up the expired tuples.
- riku_iki 3y agoIs MVCC actually superior by some other considerations? Less lock contentions, transactional DML.
- masklinn 3y agoThe problem is not mvcc but postgres’ implementation details of it.
- Max-Ganz-II 3y agoIn what way? I didn't see anything obviously improper when I learned how serialization isolation worked.
- j16sdiz 3y agoA delicated full vacuum process that need full locking, how little isolation between tables, etc Lots of the pain point have been mitigated in the last ten years. It is now as simple as other comparable complex db can go (i.e. Not simple, but you can't find better product)
- masklinn 3y agoTFA covers its issues? It’s specifically compares postgres’ to other implementations’ (oracle and mysql).
- jabl 3y agoAlso the paper linked from TFA goes into the various implementation options in more detail: https://db.cs.cmu.edu/papers/2017/p781-wu.pdf https://db.cs.cmu.edu/papers/2017/p781-wu.pdf
- drkp 3y ago_And_ it wasn't even originally designed to be used for concurrency control at all...
- no_wizard 3y agoCan the MVCC implementation be swapped via Postgres extensions?
- apavlo 3y agoNo. It would be a major surgery on the internals. See the article for my comment at the attempt to do this with the Zheap project: https://wiki.postgresql.org/wiki/Zheap https://wiki.postgresql.org/wiki/Zheap
- jabl 3y agoShame that zheap seems to have fizzled out. Do you think there's any prospect of it being resurrected and eventually mainlined?
- BohanOT 3y agoI think there is a new project from the Postgres community. They try to replace the storage engine to solve the inefficiency caused by MVCC https://github.com/orioledb/orioledb https://github.com/orioledb/orioledb
- rch 3y agoDepending on the use case, I'd consider a foreign data wrapper.
- garyclarke27 3y agoClever Clickbait - Of course at the end of the article they offer a solution - their product (and of course it’s AI enhanced) to the problem they have overhyped.
- joevandyk 3y agoI've personally ran into the problems mentioned in the article many times, unsure it's "overhyped".
- spprashant 3y agoIt's a problem, but not an AI problem. It has a clear cause and obvious mitigation strategies.
- emmelaich 3y agoIf there was a clear cause and obvious mitigation strategies then they would have been built into Postgres already.
- riku_iki 3y ago> and of course it’s AI enhanced did they mention LLM/ChatGPT?..
- dang 3y agoI asked them to take that bit out at the end and it looks like they did. General remark for startups wanting attention on HN: it's not good to end an interesting article with a call-to-action that makes your article feel like an ad. Readers who read to the end experience that as a bait-and-switch and end up feeling betrayed. What works much better is to disclose right up front what your startup is and how it's related to the article content. Once you've gotten that out of the way, the reader can then dive into the (hopefully) interesting content and end the article on a satisfying note. Btw, I have a set of notes on how to write for HN that I'm working (slowly) on turning into an essay. If anyone wants a copy, email me at hn@ycombinator.com and I'll be happy to send it. It includes the above point and a bunch more.
- spprashant 3y agoThis post has a valid point. But the last line makes it clear why they care so much about it. Yeah, table bloat and transaction ID wraparounds are terrible, but easily avoidable if you follow a few simple guidelines. Typically in my experience, best way to avoid these issues are to set sensible vacuum settings and track long running queries. I do hate the some of the defaults in the Postgres configuration are too conservative for most workloads.
- riku_iki 3y ago> I do hate the some of the defaults in the Postgres configuration are too conservative for most workloads. it is also black magic to tune them.
- LunaSea 3y agoPaying an overhead cost of 53 bytes per row is also too expensive for MVCC in my opinion.
- nextaccountic 3y agoWhat last line? The literal last line is "We’ll cover more about what we can do in our next article." Do you mean this one? > At OtterTune, we see this problem often in our customers’ databases. One PostgreSQL RDS instance had a long-running query caused by stale statistics after bulk insertions. This query blocked the autovacuum from updating the statistics, resulting in more long-running queries. OtterTune’s automated health checks identified the problem, but the administrator still had to kill the query manually and run ANALYZE after bulk insertions. The good news is that the long query’s execution time went from 52 minutes to just 34 seconds.
- cipheredStones 3y agoIt previously had this closing line, with links to their products (https://web.archive.org/web/20230426171217/https://ottertune.com/blog/the-part-of-postgresql-we-hate-the-most https://web.archive.org/web/20230426171217/https://ottertune...): > A better approach is to use an AI-powered service automatically determine the best way to optimize PostgreSQL. This is what OtterTune does. We’ll cover more about what we can do in our next article. Or you can sign-up for a free trial and try it yourself. That was removed after the article was posted to HN, at dang's suggestion - he posted about it elsewhere in these comments.
- Max-Ganz-II 3y agoMVCC for Amazon Redshift; (pdf) https://www.redshiftresearchproject.org/white_papers/downloads/multi_version_concurrency_control_and_serialization_isolation_failure.pdf https://www.redshiftresearchproject.org/white_papers/downloa... (html) https://www.redshiftresearchproject.org/white_papers/downloads/multi_version_concurrency_control_and_serialization_isolation_failure.html https://www.redshiftresearchproject.org/white_papers/downloa... I've been told, very kindly, by a couple of people that it's the best explanation they've ever seen. I'd like to get more eyes on it, to pick up any mistakes, and it might be useful in and of itself anyway to reader, as MVCC on Redshift is I believe the same as MVCC was on Postgres before snapshot isolation.
- anecdotal1 3y agoNot bad but I like this one too http://www.interdb.jp/pg/pgsql05.html http://www.interdb.jp/pg/pgsql05.html
- gregw2 3y agoThis paper, at least by my skimming, seems to describe Redshift's historic SERIALIZABLE ISOLATION level, but does not mention Redshift's newer SNAPSHOT ISOLATION capability. https://aws.amazon.com/about-aws/whats-new/2022/05/amazon-redshift-snapshot-isolation-level-support-concurrent-transactions/ https://aws.amazon.com/about-aws/whats-new/2022/05/amazon-re... For concurrency scalability, AWS now configures SNAPSHOT ISOLATION by default if you use Redshift Serverless but non-serverless still defaults to SERIALIZABLE ISOLATION.
- Max-Ganz-II 3y agoYes. I intended to write exactly this at the end of my post, but I managed to word it completely wrongly. The document describes MVCC as it has been in Redshift until about a year ago, when snapshot isolation was introduced.
- mmaunder 3y agoI must admit as a web practitioner since 1994 I have a bit of an issue with this: > In the 2000s, the conventional wisdom selected MySQL because rising tech stars like Google and Facebook were using it. Then in the 2010s, it was MongoDB because non-durable writes made it “webscale“. In the last five years, PostgreSQL has become the Internet’s darling DBMS. And for good reasons! Different DB's, different strengths and it's not a zero sum came as implied. MySQL was popular before Google was born - we used it heavily at eToys in the 90s for massive transaction volume and replacing it with Oracle was one of the reasons for the catastrophic failure of eToys circa 2001. MongoDB gained traction not because it's an alternative to MySQL or PostgreSQL. And PostgreSQL's marketshare today is on a par with Mongo and both are dwarfed by MySQL which IMO is the true darling of web DB's given it's global popularity.
- LambdaComplex 3y ago> in the 2010s, it was MongoDB because non-durable writes made it “webscale“ I think this is the best video on that topic: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- p_l 3y agoA non-trivial component to MySQL popularity was that easy installation (not necessarily administration) and comparatively low resource usage with good performance at default settings (even today one needs to run some basic calculations for postgres in production, IMO) meant that cheapest possible dynamic hosting using Linux, Apache, PHP3, and MySQL 3, was what simply was the only available option for many. This codified LAMP stack, people learned from tutorials/courses/word of mouth how to write web apps with PHP and MySQL, used cheap LAMP hosting, optionally installed LAMP servers themselves, etc. This also led to popularity of bigger reselling setups (I don't miss installing cpanel...) and services like Dreamhost. MySQL in this way gained a virtuous cycle completely unrelated to Google. Hell, most people I know, who dealt with LAMP space for years, never knew Google had anything to do with MySQL (most people that knew about it were... Lispers. Because of who built the first version of Google Ads) Even Mac OS X Server shipped with MySQL and PHP because of that, in 2001.
- vp8989 3y agoAm I correct in thinking that PG's MVCC implementation results in a worse story around offloading some mild OLAP workloads to a replica without affecting the primary? Anecdotally, it seems that MySQL handles this better but I don't understand the internals of both enough to explain why that is. https://aws.amazon.com/blogs/database/manage-long-running-read-queries-on-amazon-aurora-postgresql-compatible-edition/ https://aws.amazon.com/blogs/database/manage-long-running-re...
- h1fra 3y agoOnce you figured out all the point in this article, it's a matter of fine tuning, can take some times but eventually it will works. The only thing I still struggle with is the Table Bloat. On managed Postgres (i.e: gcp, aws) you pay for the disk, but when you can't run a VACUUM FULL because it locks the table, you end up with a lot of allocated storage for nothing and you can't shrink the disk size (at least on gcp). Storage is cheap but still feels like a waste.
- fovc 3y agohttps://reorg.github.io/pg_repack/ https://reorg.github.io/pg_repack/ Dead easy to run and no long-held locks
- jaggederest 3y agoAbsolutely critical once you get above a certain table size.
- dale_glass 3y agoThat's interesting, MVCC was the thing that drew me to Postgres to begin with! Way back I was working on an in-house inventory app written in Visual Basic against SQL Server 2000, I think. That one just put locks on tables. It had the "charming" characteristic of that if you weren't very, very careful with Enterprise Manager, loading a table in the GUI put a lock on it and just keep on holding it until that window was closed. Then the running app would eventually snag on that lock, maybe keep holding some other lock that something else would snag on, and 5 minutes later I'd hear one of the operators screaming "Nothing is working! I can't take any orders!" from the room next to me.
- miohtama 3y agoMVCC and optimistic concurrency control are very pleasant to work with for anyone who spent a decade with manually locking SQL databases. It takes the human error and developer mistakes away from the process, or protect against it. You can still slow down your queries with deadlocks, but at least you cannot corrupt your data by accident. Though, any other optimistic concurrency control scheme can be better, but PostgreSQL was at the right place at the right time when people started to leave from MySQL.
- geophile 3y agoThere are many alternatives to table locking, including more conventional row locks. MVCC is great, but this article does identify some of the puzzling design choices of the Postgres implementation. The index problems are particularly bad, and seemingly avoidable.
- bvm 3y agoREAD COMMITTED SNAPSHOT
- audioheavy 3y agoMy main takeaway from this article: as popular as Postgres and MySQL are, and understanding the legacy systems built for them, it will always require deep expertise and "black magic" to achieve enough performance and scale for hyper scale use cases. It justifies the (current) trend to have DB's built for distributed tx/writes/reads that you don't have to become a surgeon to scale. There are other DBs and DBaaS that, although not OSS, have solved this problem in a more cost-efficient way than having a team of surgeons.
- zie 3y agoI would argue, you handle the hyper-scale use case when you are actually in hyper-scale. Trying to pre-maturely optimize this is almost always a waste of time and chances are you will screw it up anyway. Almost nobody gets to that scale anyway. If you do get to that scale, you have the money and resources to fix the problem(s) at that time.
- dalyons 3y agoi mean, sort of? There is some subtly lost in this oft-repeated advice. i've worked at 3 companies now that were initially based on a single RDBMS but have outgrown the scale of what is reasonable to serve off that architecture. They are consumer scale (10s of mill) users, but not hyperscale (IMHO 100m+). The amount of engineering cost to migrate a complicated growing company/product off a mono-db architecture is astounding. Conservatively i'm talking 10+ dev years of effort, at each company. Easily 10s of millions of $$$, maybe 100m+. None of them are "finished". It's really really time consuming and hard, once you have 100s of tables, 100s of thousands of lines of code, dozens of teams, etc. I'm all about avoiding premature optimization, and its fine to start with a classic postgres. But please don't cling to that - if you see MVP success and you actually have a reasonable chance of getting to >1mill users (ie, a successful B2C product) please please dont wait to refactor your datastore to a more scalable solution. You will pay dearly if you wait too long. Absolutist advice serves noone well here - it really does depend on what your goals are as a company.
- zie 3y ago
- cyberax 3y agoYup. A lot of heavy users of Postgres eventually hit the same barrier. Here's another take from Uber: https://www.uber.com/blog/postgres-to-mysql-migration/ https://www.uber.com/blog/postgres-to-mysql-migration/ I had a similar personal experience. In my previous job we used Postgres to implement a task queuing system, and it created a major bottleneck, resulting in tons of concurrency failures and bloat. And most dangerously, the system failed catastrophically under load. As the load increased, most transactions ended up in concurrent failures, so very little actual work got committed. This increased the amount of outstanding tasks, resulting in even higher rate of concurrent failures. And this can happen suddenly, one moment the system behaves well, with tasks being processed at a good rate, and the next moment the queue blows up and nothing works. I re-implemented this system using pessimistic locking, and it turned out to work much better. Even under very high load, the system could still make forward progress. The downside was having to make sure that no deadlocks can happen.
- osigurdson 3y ago>> In my previous job we used Postgres to implement a task queuing system, and it created a major bottleneck, resulting in tons of concurrency failures and bloat Yet, every month or two an article about doing exactly this is upvoted to near the top of HN. It can of course work but might hard to replace years later once "barnacles" have grown on it. Every situation is different of course.
- guywhocodes 3y agoI've built this queue system probably 5 times, first 2-3 were failures as consumer concurrency was 1 without us noticing for hours. The bloat comes from updating the work instead of deleting I assume, did for me. There are definitely many ways to not do it right but kinda works.
- osigurdson 3y agoYeah, it is strange that hokey, home grown solutions built on top of Postgres are suddenly in vogue.
- elijaht 3y ago> Another problem with the autovacuum in PostgreSQL is that it may get blocked by long-running transactions, which can result in the accumulation of more dead tuples and stale statistics. Failing to clean expired versions in a timely manner leads to numerous performance problems, causing more long-running transactions that block the autovacuum process. It becomes a vicious cycle, requiring humans to intervene manually by killing long-running transactions. Oh man, a previous company I worked at had an issue with a hot table (frequent reads + writes) interfering with autovacuum. Many fires over a six month period arose from all of that. I was (luckily) only on an adjacent team, so I don't know the details, other than vacuums taking over 24 hours! I'm sure it could have been prevented, but it seemed horrible to debug
- fdr 3y agoyeah, this is called "cancellation." Autovacuum is very polite and tries to let go of a lock when there's a conflict. So it lets go, over and over, until it triggers a heuristic deciding "no, not succeeding in this session could be dangerous!" and then people begin to notice it. Last I checked (....a few years ago, so things may have changed,) the theory of autovacuum heuristics may not have changed much since the turn of the millennium, they're probably about due.
- zinclozenge 3y agoI guess the question is, which MVCC strategy would be the "right" one to pick for a modern relational database? The paper linked focuses on main memory databases, and being main memory allows you to do things you can't do when disk based.
- avinassh 3y agoI have same the question. I skimmed through the linked paper for conclusion, they highlight the techniques which can be used to improve, but does not say which MVCC to use for a modern database. May be I need to do a careful reading.
- zinclozenge 3y agoI took a look at https://github.com/orioledb/orioledb https://github.com/orioledb/orioledb which is a project attempting to remedy some of Postgres' shortcomings, including MVCC. It looks like they're doing something similar to MySQL with a redo log, as well as some other optimizations. So maybe this is the answer.
- fdr 3y agoOne of the weird things about Postgres MVCC is that it is "optimized for rollback," as one person memorably quipped to me. This is not to imply a design principle, it's more a description of how things ended up, and the general argument behind this quip is Postgres lacks "UNDO" segments. On the one hand, this does make the model Postgres uses admirably simple: the WAL is all "REDO," and the heap is all you need to accomplish any kind of read, but at the expense that stuff that normally would be copied off to a sequential UNDO log and then vaporized when the transaction commits and all possible readers have exited remains comingled with everything else in the main database heap, needing to be fished out again by VACUUM for purging and figuring out how to reclaim numerical space for more transactions. There may be other solutions to this, but it's one unusual quality Postgres has relative to other MVCC databases, many of which sport an UNDO log. There are downsides to UNDO, however: if a read needs an old copy of the tuple, it needs to fish around in UNDO, all the indices and synchronization need to account for this, and if there's a rollback or crash recovery event (i.e. mass-rollback of all transactions open at the time), everything has to be shuffled back into the main database storage. Hence the memorable initial comment: "Postgres is optimized for rollback."
- thinkx 3y agoComing to Postgres, UNDO logs and no vacuum https://github.com/orioledb/ https://github.com/orioledb/
- avinassh 3y agowhat is an UNDO log and how does it solve the problem?
- fdr 3y agoIn most cases[1], when you update a tuple in Postgres, a new tuple is put somewhere else in the same heap, with different visibility information, "xmin", "xmax". The old tuple remains where it is. Index pointers to it likewise remain unchanged, but a new entry is added for the new tuple. The old version gains an updated "xmax" field indicating that version was deleted at a certain logical point. Later on, VACUUM has to plow through everything and check the oldest running transaction to see whether the tuple can be "frozen" (old enough to be seen by every transaction, and not yet deleted) or the space reclaimed as usable (deleted and visible to nothing). Index tuples likewise must be pruned at this time. In systems with an UNDO log, the tuple is mutated in place and the contents of the old version placed into a sequential structure. In the case where the transaction commits, and no existing concurrent repeatable read level transactions exist, the old version in the sequential structure can be freed, rather than forcing the system to fish around doing garbage collection at some later time to obsolete the data. This could be considered "optimized for commit" instead of the memorable "optimized for rollback." On the read side, however, you need special code to fish around in UNDO (since the copy in the heap is uncommitted data at least momentarily) and ROLLBACK needs to apply the UNDO material back to the heap. Postgres gets to avoid all that, at the cost of VACUUM. [1] The exception is "HOT" (heap only tuple) chains, which if you squint look a tiny bit UNDO-y. https://www.cybertec-postgresql.com/en/hot-updates-in-postgresql-for-better-performance/ https://www.cybertec-postgresql.com/en/hot-updates-in-postgr...
- kerblang 3y agoQuestion: Why would I need more than one extra version of the same row? I would think that with transactional locking everybody else is waiting on the first update to commit before getting their own changes in, unless the db is somehow trying to lock columns-per-row instead of entire rows.
- deleted 3y ago[deleted]
- jasonwatkinspdx 3y agoThat would require all queries, including read only queries, to participate in strict two phase locking. That has very poor performance under even very mild contention, not to mention all that mutual locking and unlocking overhead between read only queries is largely un-needed. So what MVCC databases do is keep enough versions to cover the oldest running query instead. Now read only queries don't need to hold any locks at all, they just prune the newest version older than the transaction id the query started at.
- kerblang 3y agoIf my query started 1000 ms ago, and every 200ms a transaction completed, I'm perfectly fine with getting results of some/most/all of those 5 commits. I usually don't need the database to enforce a 1000-ms-old snapshot for my own sake, which is why I'm using read-committed isolation instead of repeatable read etc. Are we saying that not enforcing this delay would break the database somehow even if I'm fine with it? Edit: I should clarify that I recognize the need for one extra version, since read-committed txns shouldn't see it until it is committed. Other writes must wait for the commit until they can write, though - it seems like there's some optimistic-writing thing where we let a bunch of writes queue up for one record knowing that we're going to have to a problem when one of them commits and the others find out they should have waited before trying to write or something, because we didn't force them to acquire a write lock before writing.
- jasonwatkinspdx 3y ago
- zeroimpl 3y ago> Oracle and MySQL do not have this problem in their MVCC implementation because their secondary indexes do not store the physical addresses of new versions. Instead, they store a logical identifier (e.g., tuple id, primary key) that the DBMS then uses to look up the current version’s physical address. This doesn’t have anything to do with MVCC. I’m sure PostgreSQL could implement an index format that piggybacks on another index rather than pointing at the physical page directly, without overhauling MVCC.
- franckpachot 3y agoAnd this is wrong. Oracle stores the physical address in the index. The ROWID is the relative file number (in the tablespace) + block offset in the file + an index in the block row directory. The difference is that Oracle rows usually don't move and are updated in place. Because old version diff goes to undo segments.
- jasonhansel 3y agoIMHO part of the issue is that Postgres was built on the assumption that snapshot isolation would be widely used. I don't think this has proven to be the case. Snapshot isolation isn't as robust and straightforward as strict serializability, but it also isn't as performant as READ COMMITTED. It seems like the worst of both worlds.
- dathinab 3y agoIMHO the problem is that 1) too many people don't understand why they probably should use snapshot isolation (or stricter) and don't understand what guarantees they don't get when read committed is used 2) it's not the default, defaults matter, a lot 3) it makes transactions spurious fallible when the db can't make sure that committing two parallel write transactions won't brake the consistency guarantees, a lot of frameworks don't have the right tools to handle this, people don't expect it, it can make in the transaction interleaved interactions with other systems harder, etc. (as a side not I assumed you meant REPEATABLE READ when you said snapshot isolation, as it's the least strict isolation level which uses snapshot isolation)
- int_19h 3y agoIMO the best thing about snapshot isolation is that it's conceptually easy to understand and reason about.
- avinassh 3y agoThis was a fun read. But now I have a couple of questions 1. Since MySQL keeps delta to save storage costs, wouldn't read and writes slower because now I have to build the full version from the delta 2. On secondary indexes, they highlight the reads will be slower and also say: > Now this may make secondary index reads slower since the DBMS has to resolve a logical identifier, but these DBMS have other advantages in their MVCC implementation to reduce overhead. What are the other advantages they have to make reads faster? Compared to MySQL, I remember reading that Postgres MVCC lets you alter the table without locking. Now I found out that MySQL also does not require locks. So, how are they doing? Are there any similar posts which explain MySQL MVCC architecture?
- jabl 3y ago1. It's a backward delta. So it's only needed when a transaction touches a row that has been modified by a concurrently running transaction. (Details differing depending on isolation level etc.). Writes can be faster because only the modified attributes need to be written to the delta undo log, not the whole row. I guess reads can be faster too in some cases, e.g. less fragmentation and wasted space (better cache usage,) over time due to in-place updates, and less pointer chasing to find the correct version if the vacuuming isn't keeping up with pruning old versions. As for MySQL and locks, the original MyISAM table format used locks, but InnoDB tables are MVCC like pgsql.
- avinassh 3y ago> Writes can be faster because only the modified attributes need to be written to the delta undo log, not the whole row. what is delta undo log?
- jabl 3y agoIt's an undo log containing the deltas from the latest version (instead of the entire row), so that a previous version can be reconstructed in case of a rollback or if a concurrently running transaction needs the previous version.
- runlaszlorun 3y agoAs an aside, Andy Pavlo (one the authors here) has his CMU database course videos up on YouTube and they are tremendous. I’ve spent 2 decades developing web applications but am not exaggerating when I say that I’m 10x more knowledgable on databases having watched his courses during Covid.
- dmak 3y agoCould you share the links?
- runlaszlorun 3y agohttps://youtu.be/oeYBdghaIjc https://youtu.be/oeYBdghaIjc There are multiple years available for his first DB class but that’s the one I watched. I almost called it his ‘basic’ class but there’s literally only like one or two classes on SQL before he dives into all the various layers of the internals. There’s also a few of his advanced courses. And then you’ll see guest lectures from industry on about every one of the new DB platforms you can think of. They’re all under “CMU Database Group” on Youtube. Highly recommend.
- runlaszlorun 3y agoFor all the crap on YT, there’s some real gold if you dig and clue the algo in. The SICP lectures I’d place in this category as well.
- lmwnshn 3y agoYou can do the projects (the autograder is public) and join a discord community of non-CMU people that are following along too! e.g., [0] for Fall 2022. [0] https://15445.courses.cs.cmu.edu/fall2022/faq.html#q8 https://15445.courses.cs.cmu.edu/fall2022/faq.html#q8
- bberrry 3y agoCould it be this? https://www.youtube.com/playlist?list=PLSE8ODhjZXja7K1hjZ01UTVDnGQdx5v5U https://www.youtube.com/playlist?list=PLSE8ODhjZXja7K1hjZ01U...
- Temporary_31337 3y agoI work for a db vendor and Acid compliance (also implemented with MVCC) is a big selling point. Yet, most use cases I later see don’t require such rigid controls on updates. This means customers are paying for this as transactionally consistent updates are more expensive than eventually consistent ones.
- jonsnow_dba 3y agoWe have MySQL/MariaDB in RDS and ever since we migrated MariaDB to 10.6.12 we get at least 1 table corruption per day. Only work around available is to restart database just like windows-95.