Is mongodb database ACID compliant enough for Inventory/CRM/Accounting systems of small businesses?

13    10 Jun 2016 14:09 by u/rms_returns

I'm a programmer but know very less about the DBA level intricacies of databases. I want to understand the trade-off that one makes to achieve a better performance of mongodb against the robustness of traditional sql databases like mysql/postgresql?

If I were to implement an Accounting/CRM/Inventory system (or even an eCommerce system), how will this ACID compliance of MongoDB affect the correctness of data in each case.

I want to understand that if mongodb was lacking in ACID compliance in any way, why is it so popular choice today among lots of developers?

7 comments

5

Nope. MongoDB is not fully ACID compliant and lacks transactions. It is great for large reads and small amount of writes otherwise I would switch to something something else. A good application for Mongo is youtube or facebook likes. Its ok to miss a few per 500 or so likes without degrading user experience. If you are working on Ecommerce/CRM/Accounting I recommend you use something transactional such as mysql or postgres. Mongo is a terrible idea in this scenario.

1

No, and surely there's half a dozen RDBMS that would let me sleep better at night. Why RetardDB?

I think some people who don't want to learn SQL like it.

0

No, it isn't ACID compliant.

You can get around some of that by, say, putting all your database changes into a linear logfile, and writing a checkpoint record every now and then when you know the database is consistent. If something bad happens you can back up to that last checkpoint and re-apply those changes. That gets you "D", durability.

But the "A" and "I" require transactions of the type which can be rolled back. You can get the "A" and the "I", atomicity and isolation, by committing those changes to Mongo in complete chunks, e.g. a transaction which requires 100 changes to the database gets shoved into the logfile and the changes executed all in one go.

As for the "C", consistency, that depends on your definition of "consistent". You'll get some of that in Mongo, DB structural consistency, but things like balances on a customer record being consistent with its debits and credits? In just about any situation you're on your own for stuff like that.

If you're going to be doing accounting and inventory for 100,000,000 entities, maybe it's worth the trouble. Or as an academic exercise. But you're tolerating a lot of maintenance headaches, for a SMB system, in exchange for not paying AWS for a bunch of VMs with MySQL on them.

0

AFAIK mongodb can be considered ACID-compliant with some MASSIVE caveats, but you probably want some additional things like transactions.

It's extremely rare that you actually need nosql for performance, so don't throw away the very notable advantages of proper SQL databases for nothing. If you end up so successful that no existing SQL server is fast enough, you can probably steal some top employees from facebook and google to fix that.

mongodb/redis/etc is popular for the same reason planking was popular: a lot of people simply don't know any better.

0

ACID or ACID not. There is no 'enough'.

Writing an accounting system on mongo is pretty much grounds for a lawsuit.

-1

Mongo db is webscale.