# Is it impossible to store 2^266 records on a database of some kind? [closed]

Each records weighs 52 bytes, is it possible in today's technology if someone had the storage needed? What kind of db would hold the data and will make it possible to retrieve it.

An example record:

``````(5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAbuatmU
,1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a
,1Q1pE5vPGEEMqRcVRMbtBK842Y6Pzo6nK9)
``````

The number of records is `115792089237316195423570985008687907853269984665640564039457584007913129639936`

• Just curious, how did you come up with `266` from `52 bytes`? Apr 1, 2014 at 8:28
• 2^266 is roughly equal to 10^80. The database is a list of all the atoms in the universe. Apr 1, 2014 at 9:28
• This question appears to be off-topic because it is absurd. Apr 1, 2014 at 9:32
• This question appears to be off-topic because unicorns. Apr 1, 2014 at 9:34
• What problem are you trying to solve? Apr 1, 2014 at 9:36

Absolutely possible, because someone with the resources to store 6021188640340442162025691220451771208370039202613309330051794368412 Terabyte definitely has enough money to get a custom made database system for his purposes as well.

I might be available as a contractor, for only 0.01€ per Terabyte.

• I bid with `0.001` per PetaByte. Apr 1, 2014 at 8:30
• If you store this data on 2TB harddisks (each weighing 599 grams) the disks will have a mass of 900.000 × high end for estimated mass of the universe (≈ 2×10^60 kg ) Apr 1, 2014 at 8:40
• Isn't the logic circular? Wouldn't the 'custom database' be the resource they need, therefore not have yet? Apr 1, 2014 at 10:34
• No, the "database", i.e. the data and the storage it needs were supposed to already exist. We need a custom DBMS that doesn't time out when data retrieval takes a long time because the row in question might have to travel several thousand lightvears through the bus. (You have to be careful not to pack the bytes too densely, otherwise you create a black hole and the data will never be able to leave) Apr 1, 2014 at 10:54

You have to use compression (columnstores should do it). I suggest RLE (Run Length Encoding), you can store `(5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAbuatmU ,1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a ,1Q1pE5vPGEEMqRcVRMbtBK842Y6Pzo6nK9)` as the value and `115792089237316195423570985008687907853269984665640564039457584007913129639936` as the run length. Document properly to the end user that the database favors certain values and may have problems with storing other values. Setting expectations goes a long way when closing a sale...

Unfortunately there are only 1080 atoms in the visible universe. But with only one atom given, it could be possible to describe the data purely by its position in the universe.

The database has 2266 records with 52 bytes each, that is a database size of 52⋅2266 bytes. That means there are 25652⋅2266 ≈ 101082 possibe states the database could adopt.

Using only a single atom to place it on exactly one of a total of 101082 unique places it would be possible to describe the data stored in the database.

Unfortunately the location coordinates would contain the data as well.

(Protip: Avoid using the BOOL datatype to store every bit seperately as some database solutions convert them automatically to 8-bit INT making everything even worse.)

Improving on Remus' answer, you could use a more powerful compression, storing nothing in the database.

How would that work?

Just like the difference between a method and a generator in Python, the difference between a function that `returns` a value or `yields` it when needed. Lets call it "lazy evaluation".

As an example, assuming the table will hold all possible hands of a poker/bridge game, with a card deck of 52 cards. The number of different hands is 52!, roughly equal to 10^68 or 2^226* So, instead of actually storing all of these hands in a table, you'll need to find a way to produce them when needed.

It's similar to a "numbers" or tally table. You don't really need a table to store all numbers from 1 to 10 billion. You can produce those numbers one by one, when needed. That case is of course very simple, the next number is produced by simply adding `1` to the previous one. The poker case is a bit more complicated - but still feasible.

In conclusion, yes, you can have this in a database - using 0 bytes in storage - and only a few bytes for the code/procedure/view that will be evaluating/producing the rows.

*: was 266 a typo?

• Since the data appears to be bitcoin-related, the whole idea was probably to avoid calculating anything. Apr 1, 2014 at 11:04
• Twinkles: I agree. But won't they need to calculate the rows first, in order to store them? Apr 1, 2014 at 11:32

On an optimistic estimate, you have 100 atoms in the entire universe per record - or 2 per byte. Good luck...