[rmetzler]

TL;DR: you don't have to use one or another, use both!

Your use case, running a restaurant is certainly a mixed use case. You'll certainly want to query the latest orders if this is going from the waiter to the kitchen. But yesterday's orders aren't that much important.

As others have mentioned, this data is exactly the kind of data you would store in a relational database. Just be sure to not query for the last 10 orders or something like that. I'm not a real database expert, but I've made this mistake before and as far as I know ordering by date usually means a full table scan.

RDBMS shine when you just store your data and run interesting queries on that data whenever you want to answer a question about that data. Redis is the other way around. If you want to query your data, you'll have to think about your question ahead of time and store it in an appropriate data structure.

What I was wondering is, do you shard your data in different databases? I would guess, every customer should have their on

[justinsb]

If you have an index on the date, then selecting the last 10 orders will be very cheap, and there's no reason not to do that in a relational database - it should be near-instantaneous.

The trade-off here is that every index you add makes insertion a little bit slower, so you don't normally want to just add an index for every query.

[rmetzler]

Ok, thank you. Now you got me thinking, what did I do wrong with this Oracle 9 DB several years ago? :/

[justinsb]

Perhaps you selected the last ten orders for a particular customer, or something like that. In that case, the query planner would have to choose whether to scan the entire table, or to scan the timestamp index and then filter by customer. If you had a lot of customers, it is reasonable to choose the table scan.

Of course, for that query, you could create an index on customer_id & timestamp, and then it would be near-instant again!