misled like so many others
Well, nothing is truly unlimited 
Conventional databases have some constraints too.
Coda is catering to a wide audience. Only a fraction of it is power users. For many people and the majority of use cases, “unlimited” indeed feels like unlimited.
That’s why I said in some other thread that before any commitment, you MUST fully realize the fact that Coda is a doc. Not an app builder, not a cloud database — a doc. More user-friendly and stricter about data structure than spreadsheets, but still technically in the same category. So if your project is too big for tracking it in a single Excel file, then it’s very likely that it’s also too big for Coda.
The lack of the database behind the scenes must be a design choice. I’m not on the Coda team, so I can only speculate based on my experience in software engineering, and I’m not ready to tell why I think they went this way. But it must have been a conscious design choice at the time. Heck, I even kinda understand why they did the buttons the way they did (i.e. so that each row has its own button instance and not one declaration for the entire column).
Regarding your dataset numbers. Are those all required to be available at any time? Or the majority of it is historical data that can be tucked away / no need to recalculate it constantly? Because, frankly, if you’re dealing with 5k ongoing customers and processing lots of orders, an effort to hire a team of coders and build a bespoke piece of software sounds like a viable option to me. Not meaning to overstep my boundaries — just an outsider’s perspective on pain (value) vs cost to solve.
P.P.S. If I were hired to solve the kind of problem that you have with the volumes, my first instinct would be just that — figure out if we could split the data into the “historical” part (where nothing is linked and everything is scalar like I described above, and daily/monthly summaries for statistics are also stored as scalars in some Snapshots table) and the “working set” where live formulas and references are okay. With the capability to move data between two sets, of course (i.e. archive a customer, then “resurrect” the customer back into the working set when required)