10 ms·

For the record, I've used CouchDB multiple times and it was a mistake every one of them. Moving to Postgres never takes as much time as you'd think, and having

by sfeng 6y ago

For the record, I've used CouchDB multiple times and it was a mistake every one of them. Moving to Postgres never takes as much time as you'd think, and having a database which is rock solid, understood, and performant is a great idea. Choose a DB which you will be happy with when there's an issue at 4AM, not the one fun to use at 4PM.

j45 6y ago
There is no small amount of time wasted taking data from non relational dbs and making it relational. If you prefer nosql, consider something like Hasura which reveals a graph on top of a Postgres dB. I’m not affiliated with either but it’s important to not make tech decisions based on what a developer hears others like to use.
- cpursley 6y ago
  Hasura is a game changing server technology. It handles postgres PostGIS and Json types really well.
  - j45 6y ago
    It’s certainly one thing that made me wonder why I went in the direction of MySQL all those years ago.. from a modernization perspective it would be a bolt on for any existing Postgres db as well.
    - cpursley 6y ago
      Hasura supports or will support MySQL soon (but is not 1 for 1 with PG in terms of features).
klodolph 6y ago
The other reason I'd choose Postgres is because if it turns out you really want something more of a NoSQL style database, Postgres is still very competent.
- NicoJuicy 6y ago
  Of you didn't knew this and doing c# Checkout the DocumentStore library: MartenDb It's documentation makes it pretty clear what postgress can do concerning this and event sourcing
dSebastien 6y ago
I think that it depends on the data model / use cases. When I joined the project, I didn't understand it enough to feel how relational the model really was. It only became apparent to me later on. And by then, it was much harder to replace it. CouchDB is really nice and has cool features, but for people used to SQL, its a very different beast. Querying is surprising in many ways (less so if you're used to MongoDB I guess). As you can guess, joins across documents and the like are not really great... and often necessary for relational data. The correct approach, assuming that we'd want to continue with it would be to denormalize the data much further (which we did not do so far), and perform data reconciliation... The offline-first case did sound convincing enough to me in the beginning, because we were targeting high level executives, which probably travel a lot more often than others, and still want to be able to work. But the world ain't static.. It's a different story in post-covid world :p
- tictac-toe 6y ago
  All data is relational. If you think some data model is not relational then you haven't thought about the problem space enough :p The only valid reasons to choose non-relational databases are scalability and performance.
  - raphaelj 6y ago
    >> The only valid reasons to choose non-relational databases are scalability and performance. Agree 200%. And people seem to get a wrong idea of where this argument starts making sense. With the right indexes, I can easily handle 200req/s on my last SaaS running on a $50/m PostgeSQL. It's also significantly easier to move from a standardized relational model to a document DB than the opposite.
- imtringued 6y ago
  CouchDB is often just used for simple cloud sync in combination with PouchDB. It's like having a Google Drive integrated into your application. If you do any complicated online querying it's simply not meant for that.
forgingahead 6y ago
One interesting heuristic for promoting engineers or making "more-senior" hires for me has been: 1. Curiosity and interest in new tech, so they are keeping abreast of developments and can think of modern best practices where useful. 2. Ability to ignore the new/sexy bits when it comes to implementation decisions, because the trade-off for stability/speed to implement is necessary in a growing company.
jacquesm 6y ago
The problem with specialized databases is that people use them as a starting point at the beginning instead of realizing that that is a premature optimization which they will likely come to regret later on. Initially you are much better off by choosing a standard relational database (Postgres,MySQL,MSSQL, pick your favorite flavor) and then, when you really have to you may have to add something that is specialized. So unless there are hard technical constraints right off the bat (which is almost never the case) stick to simple.
- lmm 6y ago
  Relational databases are an extremely specialized kind of datastore that people only treat as "standard" because they've been around a long time. They're not better than the alternatives, and in many ways they're worse: by picking a relational database you're committing to difficulty deploying schema changes, difficulty sharding, an awkward square-table model and a terrible query language, and if you make the mistake of trying to use the transactional functionality that's the one actual selling point of those datastores then you're practically guaranteed to deadlock yourself in production at some point during your growth process.
  - tlarkworthy 6y ago
    Kinda with you until "terrible query language" as, in my mind, it's the best query language. You can also opt our of rigid schema by using JSON columns. Which I generally promote as a new best practice when the database is being uses as a dumb store for a smart application. It comes down to who should be the source of truth for the schema.
    - lmm 6y ago
      > Kinda with you until "terrible query language" as, in my mind, it's the best query language. It's a decent language for ad-hoc querying by humans; the problem is it's the only interface to the database that you get. It was never designed for machine use; in a modern RDBMS, 3/4 of the time to execute a pkey lookup is spent parsing the SQL string. Yes, prepared statements can help in some cases, but they come with their own overheads that make them difficult to use safely in a large system. > You can also opt our of rigid schema by using JSON columns. You can, but usually in a database-specific way, and support for that in drivers and especially at the ORM level is pretty spotty.

by sfeng 6y ago

j45 6y ago

There is no small amount of time wasted taking data from non relational dbs and making it relational. If you prefer nosql, consider something like Hasura which reveals a graph on top of a Postgres dB. I’m not affiliated with either but it’s important to not make tech decisions based on what a developer hears others like to use.

cpursley 6y ago
Hasura is a game changing server technology. It handles postgres PostGIS and Json types really well.
- j45 6y ago
  It’s certainly one thing that made me wonder why I went in the direction of MySQL all those years ago.. from a modernization perspective it would be a bolt on for any existing Postgres db as well.
  - cpursley 6y ago
    Hasura supports or will support MySQL soon (but is not 1 for 1 with PG in terms of features).

klodolph 6y ago

The other reason I'd choose Postgres is because if it turns out you really want something more of a NoSQL style database, Postgres is still very competent.

NicoJuicy 6y ago
Of you didn't knew this and doing c# Checkout the DocumentStore library: MartenDb It's documentation makes it pretty clear what postgress can do concerning this and event sourcing

dSebastien 6y ago

I think that it depends on the data model / use cases. When I joined the project, I didn't understand it enough to feel how relational the model really was. It only became apparent to me later on. And by then, it was much harder to replace it. CouchDB is really nice and has cool features, but for people used to SQL, its a very different beast. Querying is surprising in many ways (less so if you're used to MongoDB I guess). As you can guess, joins across documents and the like are not really great... and often necessary for relational data. The correct approach, assuming that we'd want to continue with it would be to denormalize the data much further (which we did not do so far), and perform data reconciliation... The offline-first case did sound convincing enough to me in the beginning, because we were targeting high level executives, which probably travel a lot more often than others, and still want to be able to work. But the world ain't static.. It's a different story in post-covid world :p

tictac-toe 6y ago
All data is relational. If you think some data model is not relational then you haven't thought about the problem space enough :p The only valid reasons to choose non-relational databases are scalability and performance.
- raphaelj 6y ago
  >> The only valid reasons to choose non-relational databases are scalability and performance. Agree 200%. And people seem to get a wrong idea of where this argument starts making sense. With the right indexes, I can easily handle 200req/s on my last SaaS running on a $50/m PostgeSQL. It's also significantly easier to move from a standardized relational model to a document DB than the opposite.
imtringued 6y ago
CouchDB is often just used for simple cloud sync in combination with PouchDB. It's like having a Google Drive integrated into your application. If you do any complicated online querying it's simply not meant for that.

forgingahead 6y ago

One interesting heuristic for promoting engineers or making "more-senior" hires for me has been: 1. Curiosity and interest in new tech, so they are keeping abreast of developments and can think of modern best practices where useful. 2. Ability to ignore the new/sexy bits when it comes to implementation decisions, because the trade-off for stability/speed to implement is necessary in a growing company.

jacquesm 6y ago

The problem with specialized databases is that people use them as a starting point at the beginning instead of realizing that that is a premature optimization which they will likely come to regret later on. Initially you are much better off by choosing a standard relational database (Postgres,MySQL,MSSQL, pick your favorite flavor) and then, when you really have to you may have to add something that is specialized. So unless there are hard technical constraints right off the bat (which is almost never the case) stick to simple.

lmm 6y ago
Relational databases are an extremely specialized kind of datastore that people only treat as "standard" because they've been around a long time. They're not better than the alternatives, and in many ways they're worse: by picking a relational database you're committing to difficulty deploying schema changes, difficulty sharding, an awkward square-table model and a terrible query language, and if you make the mistake of trying to use the transactional functionality that's the one actual selling point of those datastores then you're practically guaranteed to deadlock yourself in production at some point during your growth process.
- tlarkworthy 6y ago
  Kinda with you until "terrible query language" as, in my mind, it's the best query language. You can also opt our of rigid schema by using JSON columns. Which I generally promote as a new best practice when the database is being uses as a dumb store for a smart application. It comes down to who should be the source of truth for the schema.
  - lmm 6y ago
    > Kinda with you until "terrible query language" as, in my mind, it's the best query language. It's a decent language for ad-hoc querying by humans; the problem is it's the only interface to the database that you get. It was never designed for machine use; in a modern RDBMS, 3/4 of the time to execute a pkey lookup is spent parsing the SQL string. Yes, prepared statements can help in some cases, but they come with their own overheads that make them difficult to use safely in a large system. > You can also opt our of rigid schema by using JSON columns. You can, but usually in a database-specific way, and support for that in drivers and especially at the ORM level is pretty spotty.