I’m part of a team that uses couchbase lite in their android app to store large amount of data, they said they creates 3 databases (they call it buckets, although i know buckets are in the server only not in the android app right?)
i asked them why, they said we have in one db more than half a million entry, and when they use it the app starts to freez.
I said that even if the db has 2 million entries it shouldn’t freez. it counts on how you deal with the db not its size… but they insisted on the contrary…
So this is a complex question - and it’s not simple to answer. To start out with documents can be in a wide range of sizes up to 20 MB. So if someone has a half-million documents but each of them are 20 MB and you try to return all the documents at the same time and this is an older Android phone (possibly a very cheap older phone) - the disk I/O is going to be extremely expensive and slow. However, if someone else has a half-million documents and they are only 1K in size and you try to return them all, well now that’s a lot less information to return from disk and put into memory. Android devices come in a wide range of memory and disk configurations - so understanding your use case and what phones your end users are using is critical to understanding performance, and this is regardless of using Couchbase Lite - this is Android development in general.
So just comparing how many records is a terrible way to look at this. Couchbase Lite can store millions upon millions of records without any issues whatsoever as long as you use a good application design. What it will really come down to is:
Document Size
Optimizing your queries
Adding indexes as needed to speed up your queries
Only getting the data you need from your queries in memory to display the information on the screen or process it in business logic
I’ve had databases with 100 million records and still have queries return in milliseconds. Now of course this was on a modern Android phone (Google Pixel). I can take that same app and run it on an old Samsung J3 phone and that same query takes almost 2 seconds because the disk is so much slower on that phone. This is because the Samsung J3 phones have slower chips they use for storage and a very low amount of memory.
Hopefully, this helps out in understanding that performance isn’t something as simple to say well we can do x million records. You have to understand the data, size, hardware storage and memory, and application requirements of how much data needs to be in memory to truly understand and start to calculate what the performance will be.
Another thing @blake.meike reminded me is that no matter what you do with threads the DB is single-threaded. This is totally different than a database server running in the Cloud or on big iron. If you are using Live Queries for example - they could keep the database permanently busy reading, depending on your replication patterns. This is one reason why one might use multiple databases that really has nothing to do with data size or the number of records in the database.
Once again - it’s a complex thing to talk about and it’s not as cut and dry as one might think.
Each connection to a database (i.e. a Database object) is single threaded. You can open multiple Database objects on the same physical database file, though, and get concurrent reads or queries. You can even read while another connection is writing.
(A live query already runs in an invisible second connection on a background thread, so it doesn’t block the Database instance that started it.)
The fundamental limit, though, is that there can be only one writer to a database at once. If two connections both try to write, one will block until the other finishes.
As always, if your app is running into performance problems, you should use the profiling tools at your disposal to analyze what’s going on. I’m not an Android developer so I don’t know what kind of profiling tools there are, but I’m sure they exist. Use them.