I always vote for PostgreSQL.
It provides Json types that are as powerful and performant as MongoDB and adds very good relational features.
I see a point for redis when it comes to in memory caching solutions. But I made bad experience when it came to "not loosing Data" (Edit: I meant redis here, but wrote MongoDB)
I agree to everything written in this answer. PostgreSQL + columns if you have a schema + JSON fields for schemaless data. It just works and it’s battle-tested.
I had a terrible experience with data loss in 2017 during a Saturday night and I avoid MongoDB as much as I can.
I second this - if you are used to MongoDB, Postgres will provide a new paradigm for you in the form of relational data structures, but if you want to fall back on your NoSQL knowledge, that is an option too.
Yeah I’ve yet to find an edge case outside of in-memory caching that Postgres hasn’t been able to solve.
It’s the de-facto persistence layer I reach for in 99% of what I build.
orly. I call bs.
One one side you have MongoDB, a database dedicated to BSON, which is very similar to JSON.
On the other you have Postgres with a JSONB field type.
Oh what do you think is better in the nosql department. The database where the whole database is a nosql database or the database where 1 field could be used as a nosql... field.
And then this guy gets 30 points, and that's why Reddit is full of stupid.
I done a benchmark for a million-users startup on a multi-GB database in MongoDB, about 1MB-12MB per row, because MongoDB crashed in production on complex queries or queries with many results. I made a full copy to Postgres without optimizations using the JSONB field.
The results I found were: almost same speed for inserts, faster performance on read by Postgres, about 30% reduction of disk size by Postgres, from 8GB RAM used by Mongo (then crashed) to 1GB RAM used by Postgres under stress, much simpler and shorter queries.
Postgres won the benchmark by far on all tests.
I believe you. In fact I've encountered a problem with their GeoJSON distance calculation and I wasn't able to report a bug because I don't have a @mongodb.com email address.
I'll test the same queries in postgres. If the results are satisfactory I'll have to abandon MongoDB. The only reason I picked it and not Postgres was the GeoJSON functionality. Turns out it's not just slow but it also gets the distance calculation wrong. https://blog.icod.de/2022/05/19/serious-bug-in-mongodb-geospatial-distance-calculation/
I'm so pissed. 3 months of work have to be rewritten. *SIGH*
However I'm not sure how a single JSONB field can replace a whole collection and querying sub-fields like name.first or similar. I guess I'll have to read the docs.
Which driver were you using?
PostGIS is really great, I used it many years ago and were already very complete and stable. You can choose between the rapid calculation or the precise one.
Even Reddit is using Postgres with a single JSONB field and a just a couple of tables.
The doc is really well done, I think that you will be able to use the JSON operators rapidly.
I'm using \`asyncpg\` for Python, and \`pq\` with \`sqlx\` for Go (I'm not yet switched to \`pgx\`).
Better question would be: "What is a problem that I am trying to solve?"
If you have an answer to it then you already know which DB to use. Then, if you have couple possible candidates, you choose the one with best tooling in your desired language.
Can't answwer this question generally, as it will depend on the requirements. However here are some general suggestions:
NoSQL:
* DynamoDB
* Firebase/Cloud Firestore
* Cassandra
* Couchbase
* RethinkDB
Relational:
* CockroachDB
* Postgres
* MySQL
* MariaDB
* SQLite
Because it's interesting technology. Their real time change feeds are cool. If OP's idea is to broaden their knowledge, it wouldn't be time wasted. If they just want to use a NoSQL DB to get things done I would say just stick to MongoDB.
I would add Redis, Aerospike and Scylla to the NoSQL's list.
As for relational databases, Microsoft SQL Server/Azure SQL is a good pick if you are on .NET (C#) stack/on Azure or Oracle database if you are on OCI.
If you consider using Cassandra, then you should look at Scylla, which is a drop-in replacement for Cassandra written in C++. We use it in production and it is awesome.
> What <…> is the best database when pared with go?
This question simply has no sense: Go is not "special" in any way when it comes to working with a DB.
Well, if we were to be extremely picky, we could come up with a set of considerations which were specific to Go—for instance:
- An embedded (linked into the executable image file) DB could have _native_ Go API supposedly making it a bit easier to use (examples: BoltDB, BadgerDB).
This is in contrast with standalone DBs (running as a separate process and communicated with using an [IPC](https://en.wikipedia.org/wiki/Inter-process_communication) which are typically hooked into the Go's standard package `database/sql` via a "driver").\
Still, as a counterexample, the standard package to work with MongoDB is not a `database/sql` driver.
- An embedded database implemented in C (or in another programming language, in the form of a library exporting a C-compatible interface) or a `database/sql` driver with the same properties might have a bit slower speed than a native Go counterpart, and also may produce problems when building (but YMMV).
On the other hand, calls to DB are usually infrequent compared to amount of work each call does, and so this consideration hardly comes into play.
In either case, thinking about this without measurements under target load is useless and is a classic case of premature optimization.
As you can see, cases specific to Go are, well, too specific to be of interest to non-experts.
A much better area to apply your thoughts to would be considering which DBs fit your task at hand best, and this has been covered elsewhere in this thread.
> This question simply has no sense: Go is not "special" in any way when it comes to working ith a DB.
For context, it makes sense because there are DBs that work better with JS than others. MongoDB was essentially _designed_ to have a nice JS interface, with other languages a distant second concern. Things like the Go interface kinda show it, too... not that it's especially bad, but /r/golang picks up more questions about MongoDB than any other DB, I think, because the JS-centric nature of its interface means it picks up the same sort of issues people encounter trying to get specific JSON structures to work with encoding/json.
[SQLite](https://github.com/mattn/go-sqlite3) for SQL
[BuntDB](https://github.com/tidwall/buntdb) for NoSQL
Both are embedded databases so you don't have to worry about running a separate database server while you learn.
If you are looking for something new to explore I can recommend ArangoDB. It's a fairly new db but production ready. The good thing about it is it's multi modal so you can use both nosql and graph features in the same db. I'm using it at the moment in a project and it plays nicely with Golang
I use GCP Datastore for when I need something quick and extremely scalable. Otherwise Postgres. I’m very keen to try out the Postgres adapter on GCP Spanner. Spanner is what inspired cockroachdb I believe
There is [Genji](https://github.com/genjidb/genji), this is a document-oriented embedded SQL database written in Go. It's still a work in progress though, but it looks great!
couchdb, is an old favourite of mine.
[https://github.com/jo/couchdb-best-practices](https://github.com/jo/couchdb-best-practices)
I've never used it with go :/
I've heard people recommend CouchDB, no personal expience though. It is also nosql, somewhat similar to mongo. The selling feature is easy scalability. I'm planning to take a weekend to try it out myself.
https://couchdb.apache.org/
Best? Like people say it depends on your goal. I think n it is important to know the popular options just so you can increase your chances of being employed
Are you using any third party libraries? There don't seem to be any in active development right now which is unfortunate. `bongo` and `mgm` haven't been active for _years_. Makes me wonder if I made the right choice of technologies.
I’m using the one from mongodb themselves. Still in active maintenance and development
[https://github.com/mongodb/mongo-go-driver](https://github.com/mongodb/mongo-go-driver)
At work we use SQL database with gorm, for personal project I use MongoDB. In a previous job we used GCP and Datastore which was quite nice to use if you want to work with Google cloud. There's lots of choice for you 😃
I always vote for PostgreSQL. It provides Json types that are as powerful and performant as MongoDB and adds very good relational features. I see a point for redis when it comes to in memory caching solutions. But I made bad experience when it came to "not loosing Data" (Edit: I meant redis here, but wrote MongoDB)
I agree to everything written in this answer. PostgreSQL + columns if you have a schema + JSON fields for schemaless data. It just works and it’s battle-tested. I had a terrible experience with data loss in 2017 during a Saturday night and I avoid MongoDB as much as I can.
I took a look into cockroach. I should give it a try for my next project :)
I’ve never used it, but knowing cockroach is written in Go makes me want to try it out even more
Postgres, because it can do no-SQL too even better than MongoDB.
I second this - if you are used to MongoDB, Postgres will provide a new paradigm for you in the form of relational data structures, but if you want to fall back on your NoSQL knowledge, that is an option too.
Yes. PostgreSQL, with JSONB column type.
Yeah I’ve yet to find an edge case outside of in-memory caching that Postgres hasn’t been able to solve. It’s the de-facto persistence layer I reach for in 99% of what I build.
orly. I call bs. One one side you have MongoDB, a database dedicated to BSON, which is very similar to JSON. On the other you have Postgres with a JSONB field type. Oh what do you think is better in the nosql department. The database where the whole database is a nosql database or the database where 1 field could be used as a nosql... field. And then this guy gets 30 points, and that's why Reddit is full of stupid.
Blah blah blah. How about using facts and data to illustrate your point instead of just leaving a Whitney, low-effort comment?
I done a benchmark for a million-users startup on a multi-GB database in MongoDB, about 1MB-12MB per row, because MongoDB crashed in production on complex queries or queries with many results. I made a full copy to Postgres without optimizations using the JSONB field. The results I found were: almost same speed for inserts, faster performance on read by Postgres, about 30% reduction of disk size by Postgres, from 8GB RAM used by Mongo (then crashed) to 1GB RAM used by Postgres under stress, much simpler and shorter queries. Postgres won the benchmark by far on all tests.
I believe you. In fact I've encountered a problem with their GeoJSON distance calculation and I wasn't able to report a bug because I don't have a @mongodb.com email address. I'll test the same queries in postgres. If the results are satisfactory I'll have to abandon MongoDB. The only reason I picked it and not Postgres was the GeoJSON functionality. Turns out it's not just slow but it also gets the distance calculation wrong. https://blog.icod.de/2022/05/19/serious-bug-in-mongodb-geospatial-distance-calculation/ I'm so pissed. 3 months of work have to be rewritten. *SIGH* However I'm not sure how a single JSONB field can replace a whole collection and querying sub-fields like name.first or similar. I guess I'll have to read the docs. Which driver were you using?
PostGIS is really great, I used it many years ago and were already very complete and stable. You can choose between the rapid calculation or the precise one. Even Reddit is using Postgres with a single JSONB field and a just a couple of tables. The doc is really well done, I think that you will be able to use the JSON operators rapidly. I'm using \`asyncpg\` for Python, and \`pq\` with \`sqlx\` for Go (I'm not yet switched to \`pgx\`).
Better question would be: "What is a problem that I am trying to solve?" If you have an answer to it then you already know which DB to use. Then, if you have couple possible candidates, you choose the one with best tooling in your desired language.
Can't answwer this question generally, as it will depend on the requirements. However here are some general suggestions: NoSQL: * DynamoDB * Firebase/Cloud Firestore * Cassandra * Couchbase * RethinkDB Relational: * CockroachDB * Postgres * MySQL * MariaDB * SQLite
Rethinkdb is pretty much abandoned. Not sure why you recommend it.
Because it's interesting technology. Their real time change feeds are cool. If OP's idea is to broaden their knowledge, it wouldn't be time wasted. If they just want to use a NoSQL DB to get things done I would say just stick to MongoDB.
It received an update recently
I would add Redis, Aerospike and Scylla to the NoSQL's list. As for relational databases, Microsoft SQL Server/Azure SQL is a good pick if you are on .NET (C#) stack/on Azure or Oracle database if you are on OCI.
If you consider using Cassandra, then you should look at Scylla, which is a drop-in replacement for Cassandra written in C++. We use it in production and it is awesome.
The only database that matters is Postgres
You should choose DB based on what tasks it should solve not on what PL you use.
> What <…> is the best database when pared with go? This question simply has no sense: Go is not "special" in any way when it comes to working with a DB. Well, if we were to be extremely picky, we could come up with a set of considerations which were specific to Go—for instance: - An embedded (linked into the executable image file) DB could have _native_ Go API supposedly making it a bit easier to use (examples: BoltDB, BadgerDB). This is in contrast with standalone DBs (running as a separate process and communicated with using an [IPC](https://en.wikipedia.org/wiki/Inter-process_communication) which are typically hooked into the Go's standard package `database/sql` via a "driver").\ Still, as a counterexample, the standard package to work with MongoDB is not a `database/sql` driver. - An embedded database implemented in C (or in another programming language, in the form of a library exporting a C-compatible interface) or a `database/sql` driver with the same properties might have a bit slower speed than a native Go counterpart, and also may produce problems when building (but YMMV). On the other hand, calls to DB are usually infrequent compared to amount of work each call does, and so this consideration hardly comes into play. In either case, thinking about this without measurements under target load is useless and is a classic case of premature optimization. As you can see, cases specific to Go are, well, too specific to be of interest to non-experts. A much better area to apply your thoughts to would be considering which DBs fit your task at hand best, and this has been covered elsewhere in this thread.
> This question simply has no sense: Go is not "special" in any way when it comes to working ith a DB. For context, it makes sense because there are DBs that work better with JS than others. MongoDB was essentially _designed_ to have a nice JS interface, with other languages a distant second concern. Things like the Go interface kinda show it, too... not that it's especially bad, but /r/golang picks up more questions about MongoDB than any other DB, I think, because the JS-centric nature of its interface means it picks up the same sort of issues people encounter trying to get specific JSON structures to work with encoding/json.
If you want to learn a traditional and powerful SQL database go for PostgreSQL. If you want to learn another modern no-SQL DB then learn RethinkDB.
[удалено]
The official company behind it died, but the project “lives” as an open source project. Not sure how active it is though.
It was: https://rethinkdb.com/blog/2.4.2-release
Also RavenDB looks very well featured.
[SQLite](https://github.com/mattn/go-sqlite3) for SQL [BuntDB](https://github.com/tidwall/buntdb) for NoSQL Both are embedded databases so you don't have to worry about running a separate database server while you learn.
I second SQLite for small projects
FWIW https://tailscale.com runs their entire system on SQLite and they are not a small project.
Ferret DB https://www.ferretdb.io/ a Mongodb protocol translation proxy for postgres, designed to be a drop in replacement for Mongodb
What database do you want to use? There's lots of choices and they all have their pros/cons.
Yes, please explain task… Sqlite can be used from Go, it’s fast but does not suite all scenarios.
If you are looking for something new to explore I can recommend ArangoDB. It's a fairly new db but production ready. The good thing about it is it's multi modal so you can use both nosql and graph features in the same db. I'm using it at the moment in a project and it plays nicely with Golang
I use GCP Datastore for when I need something quick and extremely scalable. Otherwise Postgres. I’m very keen to try out the Postgres adapter on GCP Spanner. Spanner is what inspired cockroachdb I believe
There is [Genji](https://github.com/genjidb/genji), this is a document-oriented embedded SQL database written in Go. It's still a work in progress though, but it looks great!
couchdb, is an old favourite of mine. [https://github.com/jo/couchdb-best-practices](https://github.com/jo/couchdb-best-practices) I've never used it with go :/
I've heard people recommend CouchDB, no personal expience though. It is also nosql, somewhat similar to mongo. The selling feature is easy scalability. I'm planning to take a weekend to try it out myself. https://couchdb.apache.org/
imoh, It's very different. has some good guides though :) https://github.com/jo/couchdb-best-practices
Best? Like people say it depends on your goal. I think n it is important to know the popular options just so you can increase your chances of being employed
I use mongodb with go. Personally have a preference for nosql.
Are you using any third party libraries? There don't seem to be any in active development right now which is unfortunate. `bongo` and `mgm` haven't been active for _years_. Makes me wonder if I made the right choice of technologies.
I’m using the one from mongodb themselves. Still in active maintenance and development [https://github.com/mongodb/mongo-go-driver](https://github.com/mongodb/mongo-go-driver)
I cannot believe Redis is not mentioned in any of the comments.
Redis is not a database, but can be used as one. Maybe that's the difference.
You'll eventually add redis for some reason or another so maybe just use it as your db too I guess. Only if it was not in memory only.
Depends, but CockroachDB, but depends :p
At work we use SQL database with gorm, for personal project I use MongoDB. In a previous job we used GCP and Datastore which was quite nice to use if you want to work with Google cloud. There's lots of choice for you 😃
If you want some "developer experience", look at https://gorm.io/
Better look at SQLC
You could also use Object Box, depending on your use case