Storing entries in a very large database
Store one at a time until you absolutely cannot anymore, then design something else around your specific problem.
SQL is a declarative language, meaning "give me all records matching X" doesn't tell the db server how to do this.  Consequently, you have a lot of ways to help the db server do this quickly even when you have hundreds of millions of records.  Additionally RDBMSs are optimized for this problem over a lot of years of experience so to a certain point, you will not beat a system like PostgreSQL.
So as they say, premature optimization is the root of all evil.
So let's look at two ways PostgreSQL might go through a table to give you the results.
The first is a sequential scan, where it iterates over a series of pages, scans each page for the values and returns the records to you.  This works better than any other method for very small tables.  It is slow on large tables.  Complexity is O(n) where n is the size of the table, for any number of records.
So a second approach might be an index scan.  Here PostgreSQL traverses a series of pages in a b-tree index to find the records.  Complexity is O(log(n)) to find each record.
Internally PostgreSQL stores the rows in batches with fixed sizes, as pages.  It already solves this problem for you.  If you try to do the same, then you have batches of records inside batches of records, which is usually a recipe for bad things.
I am writing a Django application that will have entries entered by users of the site. Now suppose that everything goes well, and I get the expected number of visitors (unlikely, but I'm planning for the future). This would result in hundreds of millions of entries in a single PostgreSQL database.
As iterating through such a large number of entries and checking their values is not a good idea, I am considering ways of grouping entries together.
Is grouping entries in to sets of (let's say) 100 a better idea for storing this many entries? Or is there a better way that I could optimize this?