Have a look at the technical specifications at the following link:
Essentially you are restricted only on how much disk space you have.
I think the short answer is that it is more likely that your system capacity, memory size and disk space will be the limiting factor rather than your FileMaker database.
The maximum size for a single FileMaker is 8 terabytes.
Let's say we have million/s of data, can we still use FileMaker to store our data?
Millions of record can certainly be stored in a FIleMaker database, as Paul and Simon have confirmed, and in fact the platform supports up to a million tables, as the technical specifcations attest.
Apart from physical limitations such as storage space, the main consideration (and potential limiting factor) is performance. Solution design parameters that are swift and elegant when working with a modest amount of data may prove more cumbersome as the volume of data becomes large. So while there is no reason not to consider FileMaker to store millions of records, you should be selective about the techniques and design approach in order to avoid bottlenecks that would be of little concern in a smaller solution.
You will, for example, want to avoid frequently sorting or resorting of large found sets of records (sorting smaller found sets will be fine), performing finds on unstored calculation fields, or including summary fields on layouts where high record counts will commonly be displayed. You may want to configure large reports to run using offline, batch or server-side processing to avoid tying up client workstations (and consuming massive network resources) to run lengthy analyses in real time. And so on...
So, in short, it can certainly be done, but you should be cautious and selective about the design approach to ensure the solution will scale well to handle the volumes of data you anticipate.
R J Cologon, Ph.D.
FileMaker Certified Developer
Author, FileMaker Pro 10 Bible
NightWing Enterprises, Melbourne, Australia
Ok, thank you for that great advice! More power
Also when dealing with a lot of records it may be better to divide the data into separate tables of common data. When FMP displays a record it first downloads all fields for the record. So if you have a table with 100 fields but only 10 are really needed to display the primary data then you have 90 fields of data that you don't currently need. But, FMP will download it all.
For example: when using a list layout of individuals you might commonly show their First and last name. You probably do not show birthday or spouses name. So when designing the database for large record counts I recommend you divide this data into multiple tables. This way you limit the amount of data downloaded to what is currently needed. In the structure below you can show just the "People::" names and have a button to show the specific 'other' data.
contact_type - for example cell, home phone, email
contact_value - of type text because it contains email address, phone numbers, etc.
Note: I would create a join table to link people together, like spouse, children, boss, co-workers.
relationship - spouse, etc.
Exactly storing the data isn't the issue it's working with it that can ge a challange. FM can search millions of indexed rows pretty quickly but if you are running reports on thousands of rows at one time then you can get bogged down pretty quick so it really depends on what you intend to do with all that data once it's in FM.