Databento launches real-time and historical APIs for US equity options at $1/month

[arbs-r-us]

MBO is not NBBO, and it's a common industry term: see CME, Exegy, Quanthouse, OnixS.

And while you keep conjuring numbers out of thin air to claim that the bandwidth requirement is 5 Gbps, it just isn't, and you haven't provided any concrete evidence for this blanket claim. I already shared exact numbers earlier that you've repeatedly ignored in your subsequent follow-ups, which gives me the feeling you're not engaging in good faith:



These numbers are verifiable from our historical API since we use the same format for both historical and real-time. We also include sequence numbers to prove that there's no conflation. There's no "math" because this is just the empirical distribution of file sizes.

56-80 * 10m = 560-800 MILLION BYTES PER SECOND. A BYTE IS 8 BITS. 4.480-6.400mbit (AND THAT'S NOT COUNTING TCP/IP OVERHEAD). Please. Stop. 10m/second IS A REAL NUMBER. Maybe you can just look here and see for yourself. https://marketdatapeaks.net/

If you have an account there, then you can select a single SIP (OPRA). The default chart is all SIPs. OPRA is typically 88% of the total.

 

[Databento]

56-80 * 10m = 560-800 MILLION BYTES PER SECOND. A BYTE IS 8 BITS. 4.480-6.400mbit (AND THAT'S NOT COUNTING TCP/IP OVERHEAD). Please. Stop. 10m/second IS A REAL NUMBER. Maybe you can just look here and see for yourself. https://marketdatapeaks.net/

If you have an account there, then you can select a single SIP (OPRA). The default chart is all SIPs. OPRA is typically 88% of the total.

Your methodology is incorrect.

This is normalized data, it doesn't map 1:1 to the raw packets.

For your convenience, we do track the exact raw feed throughput in Gbps too, so you don't have to estimate it crudely from packet rates:

 

[arbs-r-us]

Your packets are LARGER than OPRA binary packets. And MBO (as exegy and others define it), is ORDER BOOK DATA. This is NOT contained in OPRA. It's ONLY available in the direct exchange feeds. If you are COMBINING multiple exchange's quotes into one, creating a "book of sorts" which is ALL THE EXCHANGES AT A PARTICULAR PRICE, and you ONLY update that when the price changes (not the size), for sure that's going to reduce the data. But that is NOT full OPRA. You won't know where the quotes are coming from and hence won't know where to send an order(s). And your chart goes up to 5gbit/second, 1 minute samples. Exactly what I said.

 

[Databento]

Your packets are LARGER than OPRA binary packets. And MBO (as exegy and others define it), is ORDER BOOK DATA. This is NOT contained in OPRA. It's ONLY available in the direct exchange feeds. If you are COMBINING multiple exchange's quotes into one, creating a "book of sorts" which is ALL THE EXCHANGES AT A PARTICULAR PRICE, and you ONLY update that when the price changes (not the size), for sure that's going to reduce the data. But that is NOT full OPRA. You won't know where the quotes are coming from and hence won't know where to send an order(s). And your chart goes up to 5gbit/second, 1 minute samples. Exactly what I said.

I'll try one last attempt to paraphrase this in a manner that you can follow:

• The 5 Gbps peak chart you're seeing is for the raw feed. Normalization reduces the raw feed down, in our case to about 1 Gbps peak. The same pattern goes for every other normalized feed.
• e.g. On the old OPRA feed, OPRA packets went as large as 900+ bytes.
• There's very few reasons to distribute a normalized feed that's larger than the raw feed. If that were the case, you'd be better off just distributing the raw feed as-is.
• In fact, consolidating the full order books from the direct prop feeds provides you more information than OPRA, the exact opposite of what you've said. This is one of the reasons why the direct prop feeds cost about 10x as much to acquire than the OPRA feed.

I hope this clarifies. If not, I feel that your gaps in market knowledge are much more fundamental and you should actually air them in a different thread.