So glad to see PouchDB included. We use it and have generally had a great experience! We use it with CouchDB on the backend, and Couch seems like a fantastic way to go for use cases involving syncing data between devices with an offline mode and syncing between clients. It was built from the ground up with replication in mind.
Biggest bummer of CouchDB? If you’re not hosting it yourself, there’s only one major player in the market that I know of: IBM Cloudant. They contribute much to Apache CouchDB though, and hosting it yourself doesn’t seem too difficult, especially for small, simple use cases.
I use the PouchDB/CouchDB combo for exactly the use case your describing. The query language for CouchDB leaves a little to be desired, but ultimately it has worked well for me. I'm self hosting on a digital ocean droplet.
You probably need to define your actual requirements rather than this nebulous term.
The "DO offering" is a basic VPS and you host/manage the couchdb process yourself. DO does not offer a managed couchdb service. I've found couchdb to be reasonably stable and worry free.
The nature of pouchdb/couchdb and the design philosophy behind it makes it relatively easy to scale to additional servers. Couchdb is master-master, which is a good eventually consistent model that should help in any horizontal scaling. The base process is erlang/elixir which should scale vertically well.
I've been using it a couple of years, but not on any sites that have significant traffic.
"enterprise grade" covers a a much larger spectrum of uses and needs with regard to features and stability than non-enterprise grade, making it kinda hard to answer that generally.
They offer VMs, containers, managed DB instance offerings, block storage, multiple regions and datacenters, load balancing, etc. They have an API to control all those things, and modules available in many popular languages. But that's basically what many people consider table stakes for a service like that, and indeed there are competitors like Vultr and Upcloud that offer the same.
Will any of them have quite the same level of offerings that AWS or GCE or Azure offer? Probably not. But for a great many people what they have is all the enterpise level stuff they'll need or use, and it is decidedly easier to just start up a cheap linux VM and take care of it on one of these services compared to AWS or GCE or Azure, so if what you want are somewhat manually managed cloud VMs, I highly recommend one of these services over one of the big names.
I've used all the services named, and I still prefer DO for just throwing up a cheap $5-$10 VM for personal stuff, or to spin up a temporary VM for testing something out. On DO that's a couple second process when you do it manually by clicking around.
I've used AWS, Digital Ocean, and Vultr each for multiple years. I've had one major outage on AWS and another on Vultr. I'm currently feeling out Oracle cloud.
I wouldn't hesitate to run significant sites on any of these providers. Problems and outages happen, I don't think anyone is really providing five 9s whatever they say.
I tried to use couchdb with pouchdb. It was a mess to add the proper authentication layer over it and the fact that even the couchdb team has changed their opinions on the right way to do it was not impressive.
I love RxDB with Hasura behind it. It's incredible and you get a great postgres front end to boot.
One database per user. And even disregarding the obvious inability to natively join information across tables, it still was a mess to subscribe to changes across all of them and all the other things you take for granted with a relational database. And to me, it looks like couchdb is on life support as a technology. It's a great idea and revolutionary in it's time, putting everything as documents with views, etc. But, too many gaps and unclear direction.
CouchDB dev here, I can confirm that CouchDB is very much not on life support. Active work goes into PouchDB and CouchDB, some of which is addressing the issues brought up here. Nothing shipping yet (aside from maybe native jwt auth in this months 3.2.0 release), but definitely ongoing :)
Glad to hear a new release is coming. I run CouchDB in production. I have actually checked the couchdb repo to see if it was being maintained.
Some of the things that trouble me. The ubuntu upstream package manager dropped off the radar for a while, not sure if it's currently running or not. Also, the last release was a looong time ago. I understand it's pretty stable, but there are rough spots that could use some shoring up as noted.
These issues aren't enough for me drop its active use in production, but I'm eyeing reworking how I use if these kinds of issues continue. This kind of dropping the ball doesn't instill confidence. I don't want to have to maintain my own installer so I can predictably perform new installations.
Also, no Linux ARM package. I gave a go at compiling it myself for ARM, but that failed due to being unable to find/use a compatible SpiderMonkey.
It's great tech, and I'd love to carry it with me into bigger and better projects. Here hoping :)
That's great to hear. I love PouchDB for the record. It's amazing.
That's really great to hear about native JWT auth support, that is a huge gap for me to not have a good story of how to do auth. I totally understand the reasons for moving it outside of the database, but it was too much work to create and manage my own proxy on top of couchdb.
Thanks a lot for the clarification, and I'll be watching.
Jan has actually been working on per-document access control and according to the discussion it is expected to land in CouchDB 4 [1].
CouchDB doesn't move extremely fast. It's kinda boring and reliable once everything is set up - which I consider a good thing.
But I agree, it's annoying to not be able to analyse data across multiple user DBs with a single query or to build hacky solutions when listening to changes across databases.
IMHO, user databases (both CouchDB and PouchDB) are just front cache. User can mess with his data in CouchDB/PouchDB using API, so it's important to keep data in an inner database, inaccessible to user, and copy data between databases. Inner database can be a SQL database, e.g. PG with jsonb.
I've actually been using Couch DB with Pouch directly to authenticate users on a small app, with a DB per user. Tbf, my app isn't all that large or complex at this stage, so I don't know if there's any overlap in what we're doing. But from your post, relational joins aside, I can't understand what's breaking for you specifically. You're offering nebulous gripes tbf, not discrete problems.
> Couch seems like a fantastic way to go for use cases involving syncing data between devices with an offline mode and syncing between clients. It was built from the ground up with replication in mind.
Have you come across any simple examples that show offline mode and syncing between clients with replication?
syncing between clients requires a network between clients and normally, clients only have connections to servers. But if you are in a situation where clients can open TCP connections to other clients, CouchDB can sync over that.
I use couch and pouch frequently. For replication mostly.
I’ve copied airtable data to it in the past.
Recently I implemented an event store CQRS system designed to be usable offline. I considered syncing events to the client via sockets but I needed to implement diffs. So I use couch and pouch as read only side of CQRS with an append only event CouchDB. The actual data is in Postgres.
Authorization is tricky. I do not recommend trying to do document level access control. I simply added an express endpoint that allows only reads and checks the session user for which table they can access. Then pass the request to couch.
Overall works really well. I recently turned off live sync for web and react native and loop over all of my databases on a set timeout interval. I had trouble with many connections at once.
> Authorization is tricky. I do not recommend trying to do document level access control.
If you're trying to do that, true. But if you simply let the user sync his data as he pleases, auth is quite easy with the library I maintain (link in my profile).
> I had trouble with many connections at once.
Can you elaborate on how many? And Did you increase max_db_open and the necessary OS limits? I'm currently planning to go the other way, but also a bit worried that too many open connections can cause trouble.
Neat project. If the data belongs to only that user it works pretty well. I run into trouble with sharing across users on a team and individual user sharing. In that case, I see most solutions use express as middleware for the couchdb connection.
> Can you elaborate on how many?
For web, I can have as many as I want syncing. I haven’t stress tested it yet tho. I have a CouchDB in prod that throws an error message about connection limit a few times a day. This one writes and reads. It restarts the docker container to recover since I haven’t had time to investigate. You may have given me the answer :)
On React Native, I’ve had odd behavior around 5 connections. That’s where I need to periodically poll for syncing. It works out best since the user is offline most of the time and downloads infrequently.
When i used it for web I hit a max of 6 simultaneous connections in chrome. I seem to recall that it was an (intended) browser limitation - but it doesn't throw any errors, so it's not very obvious.
I forked the socket-pouch library and changed it a bit to sync unlimited db's over a single websocket connection. It worked like a charm (despite my messy code).
If you're hitting the same issues, this might be it. A non-throwing limitation in the browser runtime.
> I run into trouble with sharing across users on a team and individual user sharing. In that case, I see most solutions use express as middleware for the couchdb connection.
A shared databases where everyone can read but only some can write is very much possible with design docs. And when being flexible with assigning/revoking roles + creating/replicating data, a lot can be modelled without a proxy.
But yeah, at some point it's probably easier to use a proxy than to do weird stuff with databases and roles.
> Biggest bummer of CouchDB? If you’re not hosting it yourself, there’s only one major player in the market that I know of: IBM Cloudant.
That's the biggest problem my projects using Pouch/Couch are facing. The tech choice was made when Cloudant still had Azure datacenter support and IBM's multiple confusing changes to their Cloud brands has put it in a situation we aren't entirely happy with and I keep getting asked/pressure if I can move things back to Azure datacenters.
I don't know what I'm going to replace it with and I still wish Azure CosmosDB was more friendly to Couch replication. (It's so close, especially its Changes feed, I feel that the proxy I need probably doesn't need to do all that much I just don't think I have the budget/time to build and test such a proxy.)
Cloudant was a startup that targeted multi-cloud. At one point they supported cluster deployments to AWS and Azure. They were bought by IBM and dropped AWS support but kept Azure support for a bit longer as they built out more of "BlueMix" (early IBM Cloud brand name), and then IBM did its dance of Cloud brand names and datacenters supported and Cloudant dropped Azure support too.
Biggest bummer of CouchDB? If you’re not hosting it yourself, there’s only one major player in the market that I know of: IBM Cloudant. They contribute much to Apache CouchDB though, and hosting it yourself doesn’t seem too difficult, especially for small, simple use cases.
Anyone else using CouchDB?