<p>Hi guys,</p>
<p>I'd like to know if you have any recommendation for what database to use if I'd like to use Go to build the server for an IOS app.</p>
<p>For instance, is cassandra a good idea? How does it compare with mongodb and mysql? </p>
<p>I don't need anything in general, but more for go app.</p>
<hr/>**评论：**<br/><br/>xsolarwindx: <pre><p>PostgreSQL is the answer 99.9% of the time. </p></pre>timetravelhunter: <pre><p>But 90% of people think they are the %.01</p></pre>geordano: <pre><p>This actually true unfortunately.</p></pre>xxorde: <pre><p>That is the right answer!</p>
<p>If you believe you are in the 0.1% region you can give Cassandra a try. But if you do not want to loose your data stay away from MongoDB.
If you want to work with your data, I mean doing more than reading / writing single data sets than take a relational database and PostgreSQL is the one to GO! :) </p></pre>skyde: <pre><p>GO Postgresql support in general is very good and it should be easy to scale it up with your need by later scale out by switching to citusData or cockroachdb.</p>
<p>I would try to stay away from mongodb and cassandra as much as possible unless you have an expert to manage it and really understand CRDT.</p></pre>Sphax: <pre><p>There's no CRDT in Cassandra or MongoDB.</p></pre>skyde: <pre><p>You can easily implement CRDT yourself on top by never updating a cell in place but only appending new data and using a merge function on read.</p>
<p>Because Cassandra is using last-write-win eventual consistency and it does not use vector clock, all in place update are risky if you care about your data. </p>
<p>For more detail see:
<a href="https://aphyr.com/posts/294-jepsen-cassandra" rel="nofollow">https://aphyr.com/posts/294-jepsen-cassandra</a></p></pre>Sphax: <pre><p>Yes. I use Cassandra daily at work, I'm quite familiar with the limitations :)
Just thought the wording was a little misleading, because cassandra does not have CRDTs in the sense that Riak has them.</p>
<p>But yeah, I agree with you.</p></pre>xxorde: <pre><p>CockroachDB is an amazing project and I like to observe the progress.
The second last time I build it, I created a DB and some tables and did some queries. Than I wanted to drop one table. But it failed. The reason was that DROP TABLE was not implemented yet!
If you want to play around like myself feel free to use CockroachDB and contribute maybe? But I would not recommend to put your production data there in the near future.</p></pre>skyde: <pre><p>Yeah I agree with you, it's still in beta at the moment and should not yet be used for production. But the team working on is very solid and should have something stable soon and pass Aphyr Jepsen test.</p>
<p>The reason I mentioned it is to say that by using Postgresql for the initial version of your application you are not tightly coupled to one product (mongodb or cassandra) and can easily switch to something that scale better but support a subset of the PostgreSQL syntax in the future without having rewrite all of you persistence code.</p>
<p>In general regular SQL database can get you very far. For example even large website like Stack overflow run on only 4 Microsoft SQL Servers. </p>
<p><a href="https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/" rel="nofollow">https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/</a></p></pre>eudaimonia_bot: <pre><p>cockroachdb is still in beta, FYI</p></pre>MrCowPie: <pre><p>I'm learning mongodb (but I have 10 year experience in relational database). I'm thinking about switching from mysql to mongo in my next personal project. May I ask why stay away from mongo? </p></pre>skyde: <pre><p>As with any other distributed database, you can check Aphyr blog and find its throwing your data away :)
- <a href="https://aphyr.com/posts/284-call-me-maybe-mongodb" rel="nofollow">https://aphyr.com/posts/284-call-me-maybe-mongodb</a>
- <a href="https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads" rel="nofollow">https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads</a></p>
<p>But there is also a bunch of very bad design decision. And while feature rich, the code quality is very bad and full of critical bug.</p></pre>xxorde: <pre><p>Here is a very got example that MongoDB can kill your project and why: <a href="http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/" rel="nofollow">http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/</a></p>
<p>I would not say that MongoDB has no usecase but I do not get why they choose to put DB in the name.</p></pre>geordano: <pre><p><a href="https://www.google.com.sg/search?q=why+you+should+not+use+mongodb" rel="nofollow">https://www.google.com.sg/search?q=why+you+should+not+use+mongodb</a></p></pre>geordano: <pre><p>Use PostgreSQL, please don't give yourself much time, you may convince yourself to use something else which is quite unnecessary.</p></pre>Iamaleafinthewind: <pre><p>It isn't really about the language, its about the data you need to manage.</p>
<p>All modern languages have perfectly functional packages for connecting to most available databases. So, that isn't a real factor.</p>
<p>Do you need to store graph data? Documents? Data that fits well into a fixed schema that is likely to change rarely if ever? Data that is highly variable and would benefit from a "schemaless" database? Do you need it to be always consistent, or is eventual consistency acceptable? </p>
<p>Keep in mind also that it's perfectly acceptable to store info in multiple databases, depending on the data domain. So, store authentication info in Postgres, time-series data in a Cassandra cluster, some documents in Postgres using the recent JSON enhancements, and maybe some key-value stuff in a Redis cluster.</p>
<p>Look at some comparison articles, which are easy to find if you include at least one of the things you are looking for info on and the term "vs". Autocomplete will start to fill out the search with similar products simply because that's what people tend to search for when they type in "postgres vs" for example. </p>
<p>If you are just doing a general app, need something to learn with, I would suggest going with Postgres. It'll serve you well with most types of data, including JSON documents, has excellent documentation, is free, and so forth. Eventually, when you think you are comfortable enough with that and the app, you can start optimizing, maybe move some data to a cassandra cluster or whatever. </p></pre>earthboundkid: <pre><p>Another factor is how many users do you have and how many transactions will you need to be able to do at once. If the OP is asking this question, they're probably a new developer and don't have many users yet. In which case, just use Postgres because it's the default until you can prove it won't work for your load. </p></pre>earthboundkid: <pre><p>Another factor is how many users do you have and how many transactions will you need to be able to do at once. If the OP is asking this question, they're probably a new developer and don't have many users yet. In which case, just use Postgres because it's the default until you can prove it won't work for your load. </p></pre>shovelpost: <pre><p>Gophers would benefit a lot from a good relational database written in Go.</p></pre>
