Home/ Questions/Q 9205899
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-18T00:04:07+00:00

I’m currently evaluating the right solution for the following app: The main goal is

  • 0

I’m currently evaluating the right solution for the following app:

  • The main goal is to track a sports tournament from multiple tablet pcs (not more than 5)
  • to be independent from internet access i’ll set up a local server in the tournament room which will serve the webapp for the tablets and a webapp for some live statistics shown by a big tv screen or projector
  • to provide an online ticker i would like to replicate the local db to a server in a datacenter which will host the website with a liveticker and use the replicated database
  • the local server will have a dynamic ip, is connected to a common router with maybe no ability to configure port forwarding and i want to be prepared for internet connection problems. So i’d guess its a good idea to push the data from the local to the public server and not vice versa like a mysql master slave replication

After some research i stumbled across couchdb because of the replication it provides and now i’ve read about the possibilities to serve the whole app by couchdb. So is couchdb a good fit for my needs or is there a better solution?
Can i handle the different webapps (tablet app for input, local live stats and online live ticker) from one single replicated couchdb database?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve been doing a lot of work with CouchDB, BigCouch and Couchbase this past year and hopefully some of my points help.

    1. The replication functionality works really well. It’s easy to initiate and I’ve always been surprised at how good of a job it does. I’ve had lots of headaches with replication in SQL Server in the past, so I’ve been pleasantly surprised at how well it works in CouchDB.

    2. There are plenty of other options however if replication is the only thing you need. CouchDB works on a document model, which is very different from a relational database. You’ll have to think of your application in a denormalized fashion since CouchDB doesn’t do “joins”.

    3. Since CouchDB communicates over HTTP and reads heavily from disk (Why are reads from CouchDB so slow? (1.5MB/s or thereabouts)). So if speed is a major, major factor, I’m not sure I would go with CouchDB. One thing I will note … I’ve found you can write your filters/views in Erlang with CouchDB and you get a major performance improvement. (I’ve seen about a 50% increase on reads).

    4. Working with dynamic IPs can be challenging with BigCouch and Couchbase. When I restarted the clusters of each technology the first time, both of them went down. You can fix this by using hostnames instead of IPs if possible and scripting some stuff with the /etc/hosts file. A nice thing about CouchDB is that it stores all its config information in databases, so I’ve always been able to look it up via Futon and make the changes I need.

    5. Check out TouchDB. They have an iOS and Android version and it’s meant to run on mobile/tablet devices and supports replication. It’s not quite production ready for Android right now, but for iOS it’s good.

    Overall I would say if you want to store things in JSON, need a document database, and want replication on demand, Couch is a good fit.

    • 0