Is Firebird 2.1 efficient to store a massive number of rows in some DB's table?

My application keeps receiving a really small event that it needs to store and I was thinking which is the best way to handle it. T开发者_运维问答he table for this event would be something like this:

EVENT
id
timestamp
some_data (integer)
fk_to_some_holder_table

If I keep storing each event as a row, will there be some disadvantage against an implementation with some kind of blob compression/treatment? Or am I going too far here?

I'm using Firebird 2.1. If needed, I could upgrade to Firebird 2.5.

Thanks in advance.

---

I'm sure you're better off with "traditional row based record":

• you want to query the records, right? Quering BLOBs is hard and slow;
• since your record size is so small you wouldn't be able to compress them, with most compression algorithms the result would probably be bigger than the separate fields require;

According to the "What are the technical limits of Firebird?" article maximum size of one table is 32TB or 16G rows.

I don't think there is any difference between 2.1 and 2.5 in this specific case, but I'd use 2.5 because of other/general improvements.

---

storing as a row makes much better sense than blobs, for the reasons already mentioned

I'd stick with 2.1 for now, 2.5 has too many bugs for my liking